Use linkifier2 to double click select links#3230
Merged
Tyriar merged 5 commits intoxtermjs:masterfrom Mar 30, 2021
Merged
Conversation
Member
|
Thanks for checking this out, I'm busy testing/stabilizing the next version of VS Code so should get to PRs within the week. |
7995c04 to
d6e5bcc
Compare
d6e5bcc to
a924a46
Compare
Also works with right click select. Fixes xtermjs#682.
a924a46 to
5185e5f
Compare
The link range is absolute, not relative to viewport
2c1df1d to
b7e0489
Compare
Tyriar
approved these changes
Mar 30, 2021
Member
|
This works really well, thanks a bunch! |
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
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.
Also works with right click select.
Fixes #682.
This relies on the fact that before a user (double/right)-clicks a link, the cursor will hover the link, triggering the asynchronous link provider(s). By the time the click event fires, the link provider "should" have done its thing, and the link is used.
If not, this falls back to the old behavior.
This seemed good enough to me. If it is not, one probably would have to expose some inner state of the linkifier to provide some way to check if there are currently link providers resolving and to wait for them to finish before selecting.
I feel a bit bad about duplicating the magic "-1"s (on both x and y for start, only on y for end) from
Linkifier2._fireUnderlineEvent, but I couldn't think of a good way to extract that logic.It seems to me to produce the correct results.