-
Notifications
You must be signed in to change notification settings - Fork 9.1k
Description
Windows Terminal version
1.15.1862.0
Windows build number
10.0.19042.0
Other Software
No response
Steps to reproduce
I know the mark mode keyboard selection is still very early days. I just wanted to make sure the expected behaviors are all covered, and I didn't see this called out.
Any hotkey that pre-exists the mark mode currently interfere with selection. That is, currently:
- Mark mode seems to only works with the default windows text navigation keys: the arrows, PgUp/PgDn, home/end.
- Selecting requires turning on mark mode and then holding shift while pressing those keys.
If the user has an "Action" configured for Ctrl+Shift+Home or Ctrl+Shift+PgUp or whatever, that action will trigger instead of the selection.
Additionally, nothing else that scrolls the buffer causes the mark to move or select:
- Scrolling with the mouse
- Scrolling with scrollToMark
- Scrolling via the command palette (Ctrl+Shift+P)
On top of that, we can't usefully turn on mark mode after scrolling, because it always appears at the bottom.
Expected Behavior
Mark mode should probably be called "selection" mode, to disambiguate with the new "marks" ...
Mark mode should disregard actions that consume Arrows/PgUp/PgDn/Home/End -- or possibly, should ignore all actions except selection-specific actions or Esc to cancel, changing all the hotkeys like a vi mode does.
The "mark" should follow the scroll buffer if the buffer is scrolled via other actions. Ideally, it should select when that happens with SHIFT pressed.
The mark should always appear within the visible buffer when it's invoked, not only at the bottom/prompt.
Actual Behavior
The mark only ever appears at the prompt, and can only be used if you haven't configured actions over the default text selection keys.