Inconsistent shift+arrow selection behavior following mouse selections compared to macOS #1706
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
CodeMirror seems to be deviating from what native text inputs and displays do on macOS when using shift+optional modifier+arrow keys after double-clicking a word, triple-clicking a line, or making a selection by clicking and dragging. The main difference is that macOS doesn't pick what side of the selection the text cursor is on until after the first shift+arrow key, while CodeMirror always assumes the text cursor is at the end of the clicked or dragged selection.
Expected behavior (as seen in any native text input on macOS):
Actual behavior: the already-selected word becomes unselected.
This also occurs with triple-clicking a line or making a selection by clicking and dragging. (For clicking and dragging, CodeMirror will place the text cursor on the side of the selection that the mouse was moving towards, in which case shift+optional modifier+right would be needed to get the unexpected behavior.) The keyboard shortcuts that this can occur with are shift+direction, shift+option+direction, and shift+command+direction. Direction includes all four arrow keys as well as page up, page down, home, end, ctrl+b, ctrl+f, ctrl+p, ctrl+n, ctrl+a, and ctrl+e. Step 2 can also be a mouse selection command (such as single or double click) while holding shift for a similar issue.
As a general rule, macOS's behavior is to act as if the text cursor is on the side of the selection that would make the first change to the selection larger. There are exceptions to this though, for example the selection will always grow if holding shift and clicking somewhere that isn't already selected.
This behavior seems to be present in both CodeMirror 5 and 6.
(As a fun aside: while all this is true for most native inputs on macOS (as well as just any text display, even if it's non-editable, such as text on a webpage), there's a surprising exception which is TextEdit. It almost has the normal behavior, except for shift+option+left following a double click specifically.)