Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR aims to address issues such as #5004.
Briefly:
It provides a new function,
guide_data()
to programmatically access values and labels (internally called 'keys') of axes and legends.Less brief:
Currently, the way to reconstruct, for example axis tick positions, is to rummage around in ggplot2's structures. As laid out by Thomas here, querying data structures is a gray area. Providing a convenient accessor to the guide information is nice for two reasons. 1) It provides a user with a reliable way to extract the information and 2), as Thomas mentions in the blog, it leaves the developers free to change internal structures without worrying too much that a downstream dependency breaks due to internal rearrangements. It should, in theory, prevent surprises such as #5063, #5029 or #3436 (comment).
WIP:
CoordSf
a bit, by capturing the logic in a function that I could reuse inguide_data()
. However, should the graticule-to-ticks logic be a ggproto method ofCoordSf
or should it live as a separate function?guide_data()
a good name? Are there better ones? I'll take suggestions.The examples reprex'ed:
Created on 2022-12-08 by the reprex package (v2.0.1)