Fix Delete(Sub)Word commands to respect active selection#3987
Open
masmu wants to merge 2 commits intomicro-editor:masterfrom
Open
Fix Delete(Sub)Word commands to respect active selection#3987masmu wants to merge 2 commits intomicro-editor:masterfrom
masmu wants to merge 2 commits intomicro-editor:masterfrom
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.
JoeKar
requested changes
Feb 7, 2026
| return true | ||
| } | ||
|
|
||
| // DeleteSelections checks for any active cursors selections and if there are it deletes them and returns true. It returns false when there are no selections. |
Member
There was a problem hiding this comment.
Can we please brake this line at the "usual" column (e.g. 80) or at least nearly as long as the rest of the comment lines in this file.
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
2 participants
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.
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