Cursor is inert on `w`/`W`/`e`/`E`/`b`/`B` when single char selection is on a one char word
See original GitHub issueIssue Description
Happens after update to 0.2.1
To reproduce:
0. Type Class.method
- Place single char selection on
.
- Hit
w
/W
/e
/E
/b
/B
Expected output:
- Cursor moves
Actual output:
- Selection stays the same
Issue Analytics
- State:
- Created 3 years ago
- Comments:13 (7 by maintainers)
Top Results From Across the Web
Text selection is one character to the right of the cursor location
I've tested in Word, Word Pad, web pages, and Excel. The behavior is consistent. My system is Windows 10 on a dell 7000...
Read more >How can I yank (copy) the single character on which the ...
I wonder, is that one character, be it Unicode, or aren't there two characters, hidden/replaced using Vim conceal feature? – VanLaser. Dec 12, ......
Read more >Off-by-one error when selecting text #1616 - GitHub
After double-clicking a word to start a selection, and growing the ... word, the selection grows to one character beyond the mouse cursor....
Read more >Mouse is selecting the text by itself
A annoying behavior happens when I click the editor at some character and just moves the pointer around, this makes a selection of...
Read more >Safari Technology Preview Release Notes - Apple Developer
Fixed non-breaking space getting inserted instead of a normal space character between text nodes in contenteditable (257136@main) ...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Ah, unfortunately I went with the complete opposite approach for the refactor. I tried wrapping all interactions with
Selection
andPosition
behind wrappers, so that operations related to line endings and non-directional selections would be handled by the wrapper, instead of by the user. I also tried re-adding the ability to select line endings a-la Kakoune.I’m also adding integration tests, so hopefully we’ll never have regressions again, provided that the various edge cases of the tricky commands are properly tested.
Now, I certainly have a preference for doing things “my” way (enforcing non-empty selections) because I like the way it works (when it does work) but I do understand that your approach has significant advantages. It might have similar drawbacks to what we currently have, though. For instance (even though it’s easy to handle), extending left or right from a selection would extend to a single-character selection, rather than two-characters.
Ah, I’m glad! There was a lot of work and experimentation going on there but we’re almost done. We might push this to master today or tomorrow, and then add some tests and update the extension in the store.