Fix Delete(Sub)Word commands to respect active selection - #3987
Conversation
Previously, Delete(Sub)WordLeft/Right commands would delete the word or subword adjacent to the cursor, even if the user had actively selected a range of text. This commit modifies `DeleteWordRight`, `DeleteWordLeft`, `DeleteSubWordRight` and `DeleteSubWordLeft`. These actions now check if a selection exists: - If yes, the existing selection is deleted. - If no, the previous behavior (select word + delete) is executed. This aligns the behavior with standard text editing conventions. Fixes micro-editor#3984
This commit introduces a new `DeleteSelections` action that acts as a global check for active selections across all cursors. If any selections exist, it deletes them and returns true, preventing subsequent chained actions from executing. The default keybindings for `deleteWordLeft` (Alt-Backspace/Ctrl-H) have been updated to chain `DeleteSelections|DeleteWordLeft`. This ensures predictable behavior in multi-cursor scenarios: If any cursor has a selection, the "Delete Selection" behavior takes precedence over directional word deletion, preventing accidental deletion of adjacent text when selections are present.
403ea57 to
bb9fd3e
Compare
| "Alt-CtrlH": "DeleteWordLeft", | ||
| "Alt-Backspace": "DeleteWordLeft", | ||
| "Alt-CtrlH": "DeleteSelections|DeleteWordLeft", | ||
| "Alt-Backspace": "DeleteSelections|DeleteWordLeft", |
There was a problem hiding this comment.
This makes the default behavior of these keys inconsistent with the default behavior of Backspace and Delete (which still don't "prevent accidental deletion of adjacent text when selections are present")?
I think we shouldn't change these default keybindings, we should just add this DeleteSelections action, and let the user rebind them to DeleteSelections|DeleteWordLeft (or rebind Delete to DeleteSelections|Delete, or Backspace to DeleteSelections|Backspace, or whatever) if the user wants to.
...Also, could you fix huge lines in the commit messages?
There was a problem hiding this comment.
This makes the default behavior of these keys inconsistent with the default behavior of Backspace and Delete (which still don't "prevent accidental deletion of adjacent text when selections are present")?
We could add DeleteSelections to Delete and Backspace as well to provide sane default bindings.
I think we shouldn't change these default keybindings, we should just add this DeleteSelections action, and let the user rebind them to DeleteSelections|DeleteWordLeft (or rebind Delete to DeleteSelections|Delete, or Backspace to DeleteSelections|Backspace, or whatever) if the user wants to.
I am fine with that as well.
...Also, could you fix huge lines in the commit messages?
Sure. What line limits do you suggest? 50/72?
There was a problem hiding this comment.
What line limits do you suggest? 50/72?
Both are fine to me. I personally use 72.
| if h.Cursor.HasSelection() { | ||
| h.Cursor.DeleteSelection() | ||
| h.Cursor.ResetSelection() | ||
| } |
There was a problem hiding this comment.
Why not:
if !h.Cursor.HasSelection() {
h.SelectWordRight()
}
h.Cursor.DeleteSelection()
h.Cursor.ResetSelection()
?
There was a problem hiding this comment.
Yes, that's more simple. I am gonna change that for DeleteWordRight, DeleteWordLeft, DeleteSubWordRight, DeleteSubWordLeft.
Previously, Delete(Sub)WordLeft/Right commands would delete the word or subword adjacent to the cursor, even if the user had actively selected a range of text.
This PR modifies
DeleteWordRight,DeleteWordLeft,DeleteSubWordRightandDeleteSubWordLeft.These functions now check
h.Cursor.HasSelection().- If a selection exists, they delete the selected text.
- If a selection does not exist, they proceed with the original behavior (select word/subword and delete it).
This ensures
microbehaves consistently with other modern text editors. When a user explicitly selects a range of text, a delete command should remove that specific range, rather than modifying the buffer based solely on cursor position relative to word boundaries.Fixes #3984