[ui] Difficult to get rid of selection area

[vadimkantorov]

In Ubuntu Terminal selection caret is not the default mode. In Windows Terminal it is hard to get rid of selection mode. Even mouse clicking away on empty area preserves it (right mouse click or Esc does the trick, but we don't need these tricks in other applications or terminals). In many terminals a single clicking is not enough to turn on selection and snapping is needed.

Strangely, hitting Ctrl+Shift+C removes selection area after copying to clipboard. This is quite annoying, since often we want to preserve the selected area (for copying again later or checking what exactly was being copied)

(Also having a typing caret and selection area active at the same time is strange, e.g. in Chrome in text fields it is not like that, though this is less critical)

Original umbrella issue: #2209

[LuanVSO]

right clicking removes the selection because it is copied to the clipboard.

Strangely, hitting Ctrl+Shift+C removes selection area after copying to clipboard. This is quite annoying, since often we want to preserve the selected area (for copying again later or checking what exactly was being copied)

since windows 10 v1809 windows include a clipboard history ui which can be opened with the key combination: win+v

[LuanVSO]

i think #4404 close this

[DHowett-MSFT]

I hope so. 😄

[vadimkantorov]

#4404 is about extending selection area and discarding selection area on ESC (discarding selection area on ESC already happens though) and some Shift-Click combo.

My issue is about the fact that a single mouse click causes selection always (which is not how it works in text editors or other terminals except cmd?). I propose that mouse click causes selection only when mosue is dragged/snapped after a click and not starting selection on a single mouse click.

[ahedderich]

I agree that this is one of the most annoying things about windows terminal. maybe a new settings-option could be implemented to deactivate this behavior.
#4404 is unrelated here.

[DHowett-MSFT]

Yeah, I have never loved the fact that you can select a single cell in the console. Some people love it, though, and every time we try to take it from them they riot. I wish I were kidding ☹️ . What are they going to do, copy a c to their clipboards? I dunno.

To that end, we coupled a "fix" for it in with people who opt for a more xterm-like experience by enabling copyOnSelect.

Is that an acceptable solution? We're trying to bridge the gap between what Windows users expect and what non-windows users might want.

[ahedderich]

The copyOnSelect option is already a very good start. Without it in the beginning it was a real pain to use.
Unfortunately it's not the final solution. What happens to me often during a day is, that i copy some command from somewhere maybe even the terminal itself and then click for whatever reason once in the terminal window, hit right click and gone is my previous clipboard.
As @vadimkantorov wrote there should be an option to enable selectOnlyOnDrag (or maybe something better named).
So if you just click somewhere nothing happens or the current selection is discarded, if you click and drag you select.
It's not a ground breaking feature but right now it feels like copy and pasting in windows terminal is like balancing a very full coffee mug. Sure, it's doable but you have to pay extra attention not to mess it up.

PS: A welcome side effect of this option if possible could also be the enabling of selection in an unfocused terminal window.
Use case: You write a documentation and you want to copy some commands that you tested in terminal into your editor.

• So the editor is active
• You click and drag on the inactive terminal window
• My expectation would be to select something ready to copy. Right now only the focus shifts to the terminal window. Nothing is selected. You have to release the mouse click start selecting again.

This behavior is great in the current state where you select things by accident but with selectOnlyOnDrag enabled the terminal could also allow selection while getting focus.
This is a really minor thing so i wouldn't open a new issue for that.

[vadimkantorov]

Also, like in ReSharper / VS, maybe some presets in Configuration would be good: "xterm" / "Gnome Terminal" / "cmd" could be introduced, so that it's super easy to set all options at once. And maybe it could be asked at first run. But of course, for the narrative "Windows is better Linux distro than Mac OS X", Linux/Mac typical terminal behaviors by defautl are nicer than cmd ones.

[DHowett-MSFT]

I honestly have never seen the value in being able to have a single-character selection. If we could build enough momentum around getting rid of that (why would you want to copy just a single character? even if so, click-drag-return to first cell would do it) would that be acceptable?

[vadimkantorov]

In wsltty one can select a single character even without “going back”, but it still requires some “snapping/dragging”, so that a single character selection (and any selection never happens at random). Same is true for other text editors like notepad or google docs

[ahedderich]

Since this issue will be resolved only in a few months at the ealiest, for the time being, i use a workaround now. It's a whole different kind of pain but maybe it helps someone:

Since the latest update brought mouse support to the terminal, i changed my zsh config to allow mouse inputs, which in effect renders the whole windows terminal mouse handling void.
To do so download the script by Stephane Chazelas and run it:

wget http://stchaz.free.fr/mouse.zsh
. ./mouse.zsh
zle-toggle-mouse

The issue here is that once a selection is started with shift+drag the starting point can't be changed without pressing any key on the keyboard to start a new selection. Also of course right click to copy won't work anymore.

As i said it's not great at all, but the frequency that i'm annoyed about those new issues during a day is less often.

[vadimkantorov]

Also one point from the OP we didn't discuss further: copying should not preferably make the selection area disappear, since after the copy one often wants to double-check what was copied or copy it again if the clipboard was rewritten for some reason (and with terminal we often copy between windows/applications, so this situation is quite often compared to a single vim session)

[DHowett-MSFT]

In PR today: removing the behavior where a lone single click without a drag selects a cell, making it so that a single click clears any active selection, and adding a distance threshold (0.25x one cell) to begin selecting

[DHowett-MSFT]

I'm marking that PR as closing this bug, because it seems to fit the brief. Vadim, what do you think?

[vadimkantorov]

In PR today: removing the behavior where a lone single click without a drag selects a cell, making it so that a single click clears any active selection, and adding a distance threshold (0.25x one cell) to begin selecting

I'm marking that PR as closing this bug, because it seems to fit the brief. Vadim, what do you think?

Excellent news! @DHowett-MSFT please go ahead :)

[ghost]

🎉This issue was addressed in #5096, which has now been successfully released as Windows Terminal Preview v0.11.1121.0.:tada:

Handy links:

• Release Notes
• Store Download