[ui] Difficult to get rid of selection area #6305

@LuanVSO commented on GitHub (Feb 5, 2020):

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 commented on GitHub (Feb 5, 2020): 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

claunia commented

@LuanVSO commented on GitHub (Feb 10, 2020):

i think #4404 close this

@LuanVSO commented on GitHub (Feb 10, 2020): i think #4404 close this

claunia commented

@DHowett-MSFT commented on GitHub (Feb 10, 2020):

I hope so. 😄

@DHowett-MSFT commented on GitHub (Feb 10, 2020): I hope so. :smile:

claunia commented

2026-01-31 00:35:24 +00:00

@vadimkantorov commented on GitHub (Feb 11, 2020):

#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.

@vadimkantorov commented on GitHub (Feb 11, 2020): #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.

claunia commented

@ahedderich commented on GitHub (Feb 13, 2020):

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.

@ahedderich commented on GitHub (Feb 13, 2020): 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.

claunia commented

2026-01-31 00:35:24 +00:00

@DHowett-MSFT commented on GitHub (Feb 14, 2020):

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.

@DHowett-MSFT commented on GitHub (Feb 14, 2020): 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.

claunia commented

2026-01-31 00:35:24 +00:00

@ahedderich commented on GitHub (Feb 14, 2020):

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.

@ahedderich commented on GitHub (Feb 14, 2020): 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.

claunia commented

@vadimkantorov commented on GitHub (Feb 14, 2020):

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.

@vadimkantorov commented on GitHub (Feb 14, 2020): 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.

claunia commented

@DHowett-MSFT commented on GitHub (Mar 6, 2020):

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?

@DHowett-MSFT commented on GitHub (Mar 6, 2020): 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?

claunia commented

@vadimkantorov commented on GitHub (Mar 6, 2020):

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

@vadimkantorov commented on GitHub (Mar 6, 2020): 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

claunia commented

@ahedderich commented on GitHub (Mar 20, 2020):

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.

@ahedderich commented on GitHub (Mar 20, 2020): 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.

claunia commented

@vadimkantorov commented on GitHub (Mar 20, 2020):

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)

@vadimkantorov commented on GitHub (Mar 20, 2020): 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)

claunia commented

@DHowett-MSFT commented on GitHub (Mar 24, 2020):

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 commented on GitHub (Mar 24, 2020): 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

claunia commented

@DHowett-MSFT commented on GitHub (Mar 24, 2020):

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

@DHowett-MSFT commented on GitHub (Mar 24, 2020): I'm marking that PR as closing this bug, because it seems to fit the brief. Vadim, what do you think?

claunia commented

@vadimkantorov commented on GitHub (Mar 24, 2020):

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 :)

@vadimkantorov commented on GitHub (Mar 24, 2020): > 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 :)

claunia commented