Record links when parsing content #208
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
At this stage we don't yet *do* anything with this information, like open the linked URL when the user touches the link (zulip#71). That will require some more infrastructure, which we build next.
This will give us a place to put "context"-flavored data structures that should be threaded down through the recursion.
This is about to get a bit more complicated, in a way that would no longer lend itself to a tidy small helper like this one.
This gives us the information that the corresponding widgets will need at build time in order to create appropriate gesture recognizers for touching the links, as part of implementing zulip#71.
|
Thanks, LGTM! Merged. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
The interesting parts of this are about tracking on each block inline container (notably each
ParagraphNode) the set of link nodes found in its subtree. We'll need that information for #71, for reasons explained there.Computing it involves adding a bit of complexity (that we were pretty much bound to eventually need for one reason or another), making the content-parser a stateful object.
This PR doesn't yet go on to have the widgets actually consume this information. I have a draft branch for that (corresponding to part of #204), but want to write some tests for it.