Add option for error bar styles

[JamieMair]

Currently, the error bar lines follow the same line style as the series:

using Plots
using Random

Random.seed!(1234)
x = collect(1:10)
y = randn(length(x))
yerr = x ./ x .* 1.0
xerr = yerr ./ 5

plot(x, y, yerror=yerr, xerror=xerr, linestyle=:dash)

However, error bars should usually be solid, or at least customisable. In this PR, I have added options :yerrorstyle and :xerrorstyle, along with aliases, to control this style working on the recipe level, and as such should apply to all/most backends.

The result is changing the plot to:

plot(x, y, yerror=yerr, xerror=xerr, linestyle=:dash, yerrorstyle=:solid, xerrorstyle=:dot)

I haven't added any tests, as I am not sure the best way to do this. Any feedback would be appreciated!

[BeastyBlacksmith]

How do you feel about making this work like

using Plots
using Random

Random.seed!(1234)
x = collect(1:10)
y = randn(length(x))
yerr = x ./ x .* 1.0
xerr = yerr ./ 5

plot(x, y, linestyle = :dash)
yerror!(x,y, yerror = yerr, linestyle = :solid)
xerror!(x,y, xerror = xerr, linestyle = :dot)

?
Then you would get control of all series attributes for free and still can use the one function call API for the simple styling.

If not, we'd had to at least rename xerrorstyle to x_error_linestyle, since there are more things to style then only linetype.

[JamieMair]

If not, we'd had to at least rename xerrorstyle to x_error_linestyle, since there are more things to style then only linetype.

This is a good idea.

I think having the option in plot would be very useful. Arguably, setting the default for the error bar style to :solid would make sense, but I didn't want this change to affect people's existing plots. Would it be okay to keep this option like this? I'll make the renames.

[codecov]

Codecov Report

Base: 80.57% // Head: 80.58% // Increases project coverage by +0.01% 🎉

Coverage data is based on head (4d4117b) compared to base (cb84997).
Patch coverage: 100.00% of modified lines in pull request are covered.

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #4360      +/-   ##
==========================================
+ Coverage   80.57%   80.58%   +0.01%     
==========================================
  Files          28       28              
  Lines        7319     7324       +5     
==========================================
+ Hits         5897     5902       +5     
  Misses       1422     1422              

Impacted Files	Coverage Δ
src/args.jl	80.22% <ø> (ø)
src/recipes.jl	67.96% <100.00%> (+0.17%)	⬆️

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

☔ View full report at Codecov.
📢 Do you have feedback about the report comment? Let us know in this issue.

[BeastyBlacksmith]

I am actually against introducing a new attribute for that. What would be reasonable is, since markerstrokecolor is affecting the color of the whole errorbars, that markerstrokestyle sets the style for the whole errorbar.

[JamieMair]

I am actually against introducing a new attribute for that. What would be reasonable is, since markerstrokecolor is affecting the color of the whole errorbars, that markerstrokestyle sets the style for the whole errorbar.

This is good enough for me. Note, that since the default for :markerstrokestyle is :solid, this will change the default behaviour, as now the code:

plot(x, y, yerror=yerr, xerror=xerr, linestyle=:dash)

will produce:

whose style can be changed via:

plot(x, y, yerror=yerr, xerror=xerr, linestyle=:dash, markerstrokestyle=:dash)

which gives:

The main issue is that :markerstrokestyle is not supported in all backends, and this gives a warning for Plots.GRBackend(). How would you feel about having a single :errorbarstrokestyle for this instead that can be supported by default in all backends?

[t-bltg]

Can this be merged ?

[BeastyBlacksmith]

In principle yes, we still have the issue that GR does not support markerstrokestyle.. I opened an issue at GR.jl

[t-bltg]

I see, jheinen/GR.jl#470.
Let's delay the merge until addressed then.