Mark Mode should preempt key bindings, and work with anything that causes scrolling...

[Jaykul]

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.

[zadjii-msft]

There's a lot to unpack here, I'll make sure this is at the top of the discussion order this afternoon EDIT: tomorrow due to some oofages. Thanks!

[zadjii-msft]

quick discussion notes:

Mark mode should probably be called "selection" mode, to disambiguate with the new "marks" ...

• meh, I think we're more attached to calling this "Mark Mode" than we are to calling the scrollbar marks "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.

• yes - we think we have an issue for this. This gets more complicated with things like nextMatch/prevMatch, find in general. We'll noodle on this one.

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.

• maybe not?

The mark should always appear within the visible buffer when it's invoked, not only at the bottom/prompt.

• for sure

over to @carlos-zamora

[carlos-zamora]

Ok, I added this to the main epic #4993. I also have a few notes on a few of these:

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.

I was wrong. No issue tracking this. So congrats, this issue is now tracking that haha.

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.

This one has an issue: #4985. I closed it because selecting by viewport automatically scrolls, which mostly satisfies the need. That said since this is the second time it's been asked for (especially after mark mode is available), I'll reopen it.

[carlos-zamora]

Mark mode should probably be called "selection" mode, to disambiguate with the new "marks" ...

• For now, scrollbar marks are in experimental so we'll rename them as a part of the polishing process. Added a comment in megathread: Scrollbar Marks #11000 to track this

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.

Fixed by #13659

The mark should always appear within the visible buffer when it's invoked, not only at the bottom/prompt.

Fixed by #13405. I need to backport that change still. Backported via #13660

[carlocardella]

quick discussion notes:

Mark mode should probably be called "selection" mode, to disambiguate with the new "marks" ...

• meh, I think we're more attached to calling this "Mark Mode" than we are to calling the scrollbar marks "marks".

Uhm... seems counterintuitive to me... "mark mode" allows to select some text, make a selection. Also, most (all) tools/editors I am aware of call this "selection", why do we want to call it "mark"?

[zadjii-msft]

why do we want to call it "mark"?

Kinda just because that's what the vintage console called it:

We've used "mark mode" internally to refer to "the editing mode in which the keyboard input modifies the selection region" for years.

That being said, "Selection mode" is pretty obvious what it's doing. And, calling it "selection mode" would immediately disambiguate it from the implementation in conhost. Idk, back to the discussion board it goes.

[ghost]

🎉This issue was addressed in #13659, which has now been successfully released as Windows Terminal v1.15.252.:tada:

Handy links:

• Release Notes
• Store Download

[ghost]

🎉This issue was addressed in #13659, which has now been successfully released as Windows Terminal Preview v1.16.252.:tada:

Handy links:

• Release Notes
• Store Download