Selection Fix #199
Selection Fix #199
Conversation
…ext by using the SHIFT+SHORTCUT+LEFT/RIGHT key combination, the selected text no longer includes the leading/trailing boundary character (such as a space)
|
It's good to base independent PRs off the master branch, so that they can be dealt with independently. But we can now first resolve the other PR and once that is merged, the other commit will be cleared from this PR automatically. |
|
Thought so. |
|
Why does Shortcut+Left/Right skip 2 boundaries, while Shift+Shortcut+Left/Right only 1? |
|
When I wrote the initial code, I realized that Shift+Shortcut+Left/Right would also select trailing/leading word boundaries, so I reduced it to 1. I wasn't sure if Shortcut+Left/Right should do the same. |
|
At least they should be consistent. The problem with skipping just one boundary is that if the cursor is at the beginning of a word and you press (Shift+)Shortcut+Left, it will only move to the end of the previous word, not to the beginning of the previous word. So probably some more sophisticated logic is needed to fix that. But I'm OK if this PR just fixes the double-click case and leaves the rest as it was (i.e. skip 2 word boundaries for the rest). |
|
That makes sense. |
|
I opened an issue for the above inconsistency so it can be dealt with separately. |
|
Cool, thank you! |
Double-click on word not to select the adjacent whitespace.
Turns out I wrote this on top of the branch I used for exposing the scroll API. Do you want me to create a separate branch without the exposure and create a PR ? Not sure what best practices are in this regard.