Apply recipes to keyword arguments#4453
Conversation
src/axes.jl
Outdated
| function attr!(axis::Axis, args...; kw...) | ||
| # first process args | ||
| plotattributes = axis.plotattributes | ||
| dummy_attributes = Dict{Symbol, Any}(:plot_object=>first(axis.sps).plt) |
There was a problem hiding this comment.
What are those needed for?
There was a problem hiding this comment.
Good question. RecipesPipeline._apply_type_recipe has
Plots.jl/RecipesPipeline/src/type_recipe.jl
Lines 18 to 25 in 399ee6a
where it asks the first argument for
:plot_object, which it then uses for pre- and postprocessing. Perhaps the function should instead be extended to accept an Axis object instead or something, this just seemed like the minimum intrusion operation to me.
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## master #4453 +/- ##
==========================================
- Coverage 80.60% 79.88% -0.73%
==========================================
Files 30 40 +10
Lines 7466 8196 +730
==========================================
+ Hits 6018 6547 +529
- Misses 1448 1649 +201 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
7ba2d7f to
2c90439
Compare
|
Has Plots moved far enough towards 2.0 that it would be difficult to revive this PR? Time is limited as always but this seems like a functionality related to eventually solving #4741, which would be useful to me, so I would be willing to make some efforts here |
|
I don't think any of the relevant portions of the code have changed, so it shouldn't be hard to port the PR. |
There are some keyword arguments which it makes sense to interpret as "on a data axis" - meaning that it would be useful to query the recipe pipeline for how to interpret user provided types.
Some such arguments that I have identified are
marker_zand friendsmarker_size(this one is questionable)So far, a number of these have been hardcoded for
UnitfulandDates, which are two of the most obvious use cases, but if a user wanted to be able to set limits in their own data type they would have to either override unexported Plots functions or handle the conversion toTuple{Float, Float}themselves. With this PR, a type recipe is enough.