Fix selection logic with shift on multi-click and in mouse mode

[Don-Vito]

PR Checklist

• Closes wordDelimiters not working inside tmux with [shift]+[left mouse click] #9382
• CLA signed.
• Tests added/passed
• Documentation updated.
• Schema updated.
• I've discussed this with core contributors already.

Detailed Description of the Pull Request / Additional comments

Currently, if selection is active, all clicks with shift pressed extend it,
i.e., shift+click, shift+double-click, shift+triple-click extend the selection
from anchor start to the current position.

While we can argue the correctness of this UX in general
(hint the terminals I checked usually do something else),
it is fully broken by #8611, that introduced cell selection on shift+click.
Currently, upon shift+double-click:

• the first click sets the selection
• the second click simply extends it
  So instead of the word we get only partial selection.

To address this I suggest to change the selection logic to:
extend only on a single-click.
I.e., shift+double-click will select a word rather than
extending an existing selection.

This is how it works in ConEmu.
However MinTTY have even smarter solution
where shift+double-click adds a word to existing selection.

[Don-Vito]

[carlos-zamora]

Huh, I think the MinTTY approach makes more sense to me. In my mind, holding shift extends the selection. So shift+double-click should extend the selection to the end of the word, whereas shift+triple-click should extend the selection to the end of the line (unless you're going up from the first selection anchor, in which case it should always go to the beginning).

Like, if you wanted to select the word as shown in your gif, just don't hold shift.

#9382 sounds more like a combination of 2 problems.

First, we get a conflict of...

1. shift means we should select, rather than send VT mouse input
2. shift means we should extend the selection

Second (easier to fix), shift+double-clicking a word when no selection is present only expands the selection to the left rather than expanding both selection anchors.

I think if we just fix the second one, we can close the bug.

[Don-Vito]

I think if we just fix the second one, we can close the bug.

Actually, this is how I tried to fix it 😄
The problem is that knowing there was no selection prior to double-click is more complex (as after the first click there is a selection already).
I can do something else: if the selection anchor is current cell, then double-click and triple-click will behave as there is no selection.
WDYT?

[carlos-zamora]

I can do something else: if the selection anchor is current cell, then double-click and triple-click will behave as there is no selection.
WDYT?

That sounds right to me! Let's do it! 😊

[Don-Vito]

Closed in favor of #9403 that takes better approach