Determine proper behavior for single-cell selection; only highlight on click + threshold-drag? #5082
Comments
ghost
added
Needs-Triage
Considering e.g. traditional mouse where clicking almost certainly includes a tiny movement too, it's probably better to introduce some drag threshold (at least that's what VTE does). |
|
Would also love it if a single non-dragging click would deselect anything currently selected. That would prevent me from having to press ESC to deselect. |
Yes that would be an excellent addition too. |
|
Honestly, it's my least favorite part of the traditional console that you can start and finish a selection with a single click. Putty's threshold is "one cell"; Console's is 0. I'd very much like to get to somewhere between 0.25 and 1 cells as our threshold. |
DHowett-MSFT
changed the title
DHowett-MSFT
added
Area-TerminalControl
|
I'm triaging this as a bug-task into v1 to force the discussion. 😄 |
Thanks, I appreciate it. This is the whole reason I go looking for console alternatives for Windows - so that they'll behave more like a Linux console in this one critical area. |
This commit rewrites selection handling at the TermControl layer. Previously, we were keeping track of a number of redundant variables that were easy to get out of sync. The new selection model is as follows: * A single left click will always begin a _pending_ selection operation * A single left click will always clear a selection (#4477) * A double left click will always begin a word selection * A triple left click will always begin a line selection * A selection will only truly start when the cursor moves a quarter of the smallest dimension of a cell (usually its width) in any direction _This eliminates the selection of a single cell on one click._ (#4282, #5082) * We now keep track of whether the selection has been "copied", or "updated" since it was last copied. If an endpoint moves, it is updated. For copy-on-select, it is only copied if it's updated. (#4740) Because of this, we can stop tracking the position of the focus-raising click, and whether it was part of click-drag operation. All clicks can _become_ part of a click-drag operation if the user drags. We can also eliminate the special handling of single cell selection at the TerminalCore layer: since TermControl determines when to begin a selection, TerminalCore no longer needs to know whether copy on select is enabled _or_ whether the user has started and then backtracked over a single cell. This is now implicit in TermControl. Fixes #4082; Fixes #4477
|
See also closely related #5099. |
|
Marking this v2-scrubbed as Kayla and I discussed scoping it into the milestone. 😄 |
|
Sorry, v1-scrubbed |
This commit rewrites selection handling at the TermControl layer. Previously, we were keeping track of a number of redundant variables that were easy to get out of sync. The new selection model is as follows: * A single left click will always begin a _pending_ selection operation * A single left click will always clear a selection (#4477) * A double left click will always begin a word selection * A triple left click will always begin a line selection * A selection will only truly start when the cursor moves a quarter of the smallest dimension of a cell (usually its width) in any direction _This eliminates the selection of a single cell on one click._ (#4282, #5082) * We now keep track of whether the selection has been "copied", or "updated" since it was last copied. If an endpoint moves, it is updated. For copy-on-select, it is only copied if it's updated. (#4740) Because of this, we can stop tracking the position of the focus-raising click, and whether it was part of click-drag operation. All clicks can _become_ part of a click-drag operation if the user drags. We can also eliminate the special handling of single cell selection at the TerminalCore layer: since TermControl determines when to begin a selection, TerminalCore no longer needs to know whether copy on select is enabled _or_ whether the user has started and then backtracked over a single cell. This is now implicit in TermControl. Fixes #5082; Fixes #4477
ghost
added
the
Resolution-Fix-Committed
|
🎉This issue was addressed in #5096, which has now been successfully released as Handy links: |
|
I just got the new version and it is now working as desired. Fantastic job guys! |
|
Glad we could help 😄 |
Environment
Steps to reproduce
Click anywhere in the text on an already focused Windows Terminal window.
Expected behavior
Window should do nothing since it is already focused. Text should not be highlighted because there has been no mouse drag.
Actual behavior
The character that's clicked on is now going to overwrite the clipboard if I right click to paste something I've just hunted out in another program or window. I will often fail to notice I've highlighted anything, and even if I do catch myself before muscle memory has completed the action, I cannot "unhighlight" text, and am basically screwed at this point. This means I have to go through with the failed paste operation, if I haven't already, and then go hunt out what I was about to paste again.
This is a pet hate of mine. Please make it so that clicking on the window is not interpreted as marking text, or at least provide an option for this. You would simply have to wait for a mouse drag event, which is what people generally do when they DO want to copy some text, so most people would not even notice this change unless they often copy a single character from a console.
The text was updated successfully, but these errors were encountered: