Shift modifer conficts between "disable mouse input" and "extend selection"

[danfoster]

Windows Terminal version (or Windows build number)

1.6.10571

Other Software

tmux 3.0a

Steps to reproduce

In Windows terminal, if you have an existing selection and then make a new selection while the shift key is held, the beginning of the selection is not changed, but instead of the selection is extended.

If you are using an application that supports mouse input (tmux in my example, but this should hold true for any application that supports mouse input), you have to hold the shift key to disable mouse input so you can natively select text in the terminal.

These 2 features conflict with each other as they are on the same modifier key (shift).

A common pattern for me in tmux, is I want to highlight some text, so I shift+select, but I miss my desired start of the selection, so I attempt to shift+select again, but due to the "extend select" feature, it doesn't move my starting position.
There is no-way I can find to clear the current selection using the mouse. My only workaround is to type a character and delete it again to clear my selection.

Expected Behavior

I would like to see a way to disable the "extend select" feature, or move it to a different modifier key, so it doesn't conflict.

Actual Behavior

See Steps to reproduce

[DHowett]

The solution we took for 1.7 is that Shift-clicking when there's no selection sets the selection start point. Is that an acceptable compromise?

[DHowett]

(with esc for dismissing the selection- sorry; I didn't consider all of the issues there)

[danfoster]

It's not ideal imo, as this differs from the behavior of terminal emulators on different OSes, which makes moving between platforms and muscle memory conflict.
My preference would be that there is some method of making shift+click always start a new selection, but I do realise it's subjective at this point.

[Don-Vito]

@DHowett, @danfoster - some terminals dismiss selection with shift click on the selection boundaries (anchor / end). We can easily implement. WDYT?

[DHowett]

I don't mind that, yeah

[YAMLcase]

I'm not sure trying to get mouse event override and extend selection to co-exist is the best approach as even long standing terminal apps struggle with this clash.

putty for instance has options to have the mouse behave like windows or xterm (or a mix of the two). I for one have never once used shift to extend my selection, I just reselect if I'm not satisfied... however I also wouldn't presume anyone else to use my workflow.

Perhaps the way to go is add a suite of options to let people decide on their own with some reasonable defaults. Here's some ideas:

• extend selection modifier key (shift, ctrl, alt, disabled)
• mouse event override modifier key (shift, ctrl, alt, disabled)

FYI, more behaviors affected by this are shift + double and triple clicking won't select the entire word/line, it only selects from the beginning of the word/line to the character you're clicking on

[zadjii-msft]

Hmm. Here's a thought: the selection anchors from #10865, we could make those draggable with the mouse even in mouse mode. Then you could just move the start anchor manually, even without shift.

Big picture there's also #1553 for more elaborate settings for mouse bindings.