Terminal: provide option for "normal" mouse selection in WSL console

[lqueryvg]

• Windows build number: (Type ver at a Windows Command Prompt)
  Microsoft Windows [Version 10.0.16299.125]

I've been redirected here from WSL...
https://github.com/Microsoft/WSL/issues/3116

Mouse selection has always been "special" in Windows terminals (for some reason its eccentric behaviour has been "ported" through to all it's relatives (ConEmu, Cmder etc) rather than being properly fixed).

Try mouse selection in your web browser to see how it should work:

Double left-click a word (on this page) then on the second click keep the left mouse button down and drag over other words. The selection will be extended to included entire words.

Triple-click should do similar for whole lines.

This works in all GUI applications on Mac, Unix & Windows and is an accepted and expected idiom. But not in a Windows command prompt.

WSL uses the Windows Console.

If Microsoft really want to embrace Unix, I suggest they take a look at the rich set of mouse selection features available in Putty or iTerm2 and use those as your benchmark (where 1. selection works "normally", 2. you can select, copy & paste without using the keyboard, and 3. you can even choose your own character selection classes) .

mintty - wsltty seems to be the only viable terminal emulator for WSL right now.

[zadjii-msft]

It's funny you should bring this up, because we've been having a lot of discussions about text selection in the recent weeks.

We've already discussed internally how

1. The WordDelimiters" reg key needs to be a actual input box on the property sheet
2. There should be separate word delimiters for selection and cursor movement. Eg, you want Ctrl+Backspace to delete the "foo" from "C:/Windows/foo", but if you double click "Windows" in that same string, you probably want the entire path.

So we should probably go ahead and add

1. triple click selects whole line
2. double click then drag extends selection

to our "selecting text kinda sucks" backlog item.

[bgshacklett]

To add one more data point, I definitely agree with 3 (triple-click selects the whole line), but 2 has me a bit confused. I don't believe I've ever seen a scenario where a double-click would select more than a single word. This is one case where sticking to idioms/standards is preferable to slightly improved features, as usability decreases significantly if you can't predict what is going to happen with a double-click.

With no offense intended, you can look to MS Word for what _not_ to do when it comes to "smart" selection. I respect that a lot of effort likely went into the algorithms used for that application, but in practice it can be extremely frustrating (e.g.: selecting part of a word and the application expands the selection to the whole word).

[zadjii-msft]

So, 2 is mostly in response to what has been a hurricane of internal mail about this feature. We actually recently "fixed" the word delimiters, but this had the unintended side effect of removing the behavior of double clicking on a part of a path to select the whole path.

We found that when people have something like

"C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\VC\Tools\MSVC\14.12.25827\bin\Hostx64\x64\dumpbin.exe" /exports "Z:\dev2\os\path\to\kernelbase.lib",

they like to click on just "kernelbase" to get all of Z:\dev2\os\path\to\kernelbase.lib.

So, the problem here comes from us overloading the "WordDelimiters" setting for the delimiters for both text selection and cursor movement.

More customization is always better here, as long as the user has all the options available to them, I'm happy.

[lqueryvg]

Exposing the "WordDelimiters" customisation to the user is exactly the right thing to do IMO. I always look for these features and tweak them to my taste. Putty calls this "Wordness" and allows the user to customise this and mouse button behaviour as depicted here:

https://github.com/lqueryvg/putty-config/blob/master/pictures/defaults/Selection.png

Xterm (>30 years old now) allows customisation via "Character Classes".
See https://www.x.org/archive/X11R6.7.0/doc/xterm.1.html#sect10

Newer tools (iTerm2 is a shining example) allow this too.
I could list more, but I'm sure you get the point.

I hope your "WordDelimiters" apply only to the console and not the whole operating system ?

FYI, if it helps...

Regarding your example, of deleting a word backwards (for Windows command prompts), in Linux I would expect Ctrl-Backspace to have no special meaning - i.e. it should be a normal Backspace. We tend to use shell line editors (emacs or vim) for deleting back a word - the terminal emulator shouldn't get involved. I expect this to be the case for lots of other key combinations too. I don't know what your internal implementation looks like, but I would encourage you to try to have the same kind of separation between the behaviour of the window on the outside and the command prompt running inside, if possible.

A quick test shows that Ctrl-Backspace just gives a backspace on WSL, which is good.

[zadjii-msft]

Regarding your example, of deleting a word backwards (for Windows command prompts), in Linux I would expect Ctrl-Backspace to have no special meaning - i.e. it should be a normal Backspace. We tend to use shell line editors (emacs or vim) for deleting back a word - the terminal emulator shouldn't get involved.

Ah and now we come to one of the big things that makes the console different from most terminals. For whatever reason, most of the line editing functionality of cmd is actually provided by conhost itself. In windows, there's not really a readline that programs can use to get processed input, instead you set the console to "Processed" input mode, and the console takes care of it for you.

Of course, many applications also make use of "raw" input mode, which is more similar to what you'd get on *nix. PSReadline uses this, and renders it's own input line, and WSL also sets the console into raw mode as well.

It does make sense to separate out that functionality, but that's been baked into how the console works for something like 30 years now. Even if we did release it as a separate lib to compile against, we'd still have to support the functionality directly in conhost anyways.

[zxbuaa]

Is there a plan just to change the word delimiter which is weird? Consider double click on fun of below text

void fun(type arg)

On whatever unix console fun is selected; however, on WSL bash.exe fun(type is selected.

[zadjii-msft]

So for the record, if you add a WordDelimiters key under HKCU\Console, you can change the word delimiters yourself manually.
I use the following (for example):

-/\:;'`".{}()[]

Obviously it'd be better if there was an actual UI for that, but implementing an actual UI for that setting is pretty far down our backlog :/

[zxbuaa]

Thanks Mike, it works (partially). The delimiter itself is selected when I click the word. e.g. word(, while I want just word(
Is there way to workaround this?

[zadjii-msft]

@zxbuaa I think that's actually just a visual bug. I believe if you copy the text, you'll find that only word gets copied.

I know we have an open work item tracking that bug, but I can't find it at the moment

[zxbuaa]

No, it seems not visual bug. I just tested on cmd.exe with copy&paste. My Windows 10 version is 1809 build 17763.379

[heaths]

As for double-clicking a "word", I prefer the cmd style where the word is between two spaces, and a lot of my workflow (and those of some coworkers, which use a derivative $prompt in powershell I wrote) relies on being able to double-click a "word" and copy the text (on a related note, Ctrl+C doesn't work like it does in "extended cmd").

[NewbieOrange]

No, it seems not visual bug. I just tested on cmd.exe with copy&paste. My Windows 10 version is 1809 build 17763.379

The word delimiters bug looks still exist in 1903?

The build is, as shown in the image, 10.0.18362.295.

[DHowett-MSFT]

On a closer read, I think this is just one of those behaviors we can't change without upsetting people (sorry!). We're focusing our main effort on Windows Terminal these days, where we _do_ have chunk selection (double-click and drag extends to words) and have made the call to not include the trailing delimiter in the selection.

[wibblewobble96]

Not sure if this is the same topic or should be raised as a separate issue, but currently when using triple-click to select a line in Windows Terminal, a full line of whitespace is highlighted after the end of all text - ideally would just highlight up to the end of the text.

[zadjii-msft]

@wibblewobble96 curiously, gnome-terminal also selects the empty space at the end of the line as well.

Technically this is a conhost thread, not a Windows Terminal thread. I'm going to comment here about the Windows Terminal, though we should make sure to generally keep the discussion about adding more selection modes to conhost.

IIRC there's also a copyWithoutWhitespace option that would trim that for you, though I forget how that works. @carlos-zamora want to chime in?

\

[carlos-zamora]

@wibblewobble96 curiously, gnome-terminal also selects the empty space at the end of the line as well.

Technically this is a conhost thread, not a Windows Terminal thread. I'm going to comment here about the Windows Terminal, though we should make sure to generally keep the discussion about adding more selection modes to conhost.

IIRC there's also a copyWithoutWhitespace option that would trim that for you, though I forget how that works. @carlos-zamora Carlos Zamora FTE want to chime in?

Windows Terminal:
A triple click highlights the entire line, correct. But a copy automatically trims the whitespace at the end of the line. @wibblewobble96, I recommend you file an issue for this feature so that we track it appropriately. :)

[nicon89]

So for the record, if you add a WordDelimiters key under HKCU\Console, you can change the word delimiters yourself manually.
I use the following (for example):

-/\:;'`".{}()[]

@zadjii-msft thank you for this. It's amazing feature.
Unfortunately as @zxbuaa noticed it's selecting also special character at the end of line (or let's call it a "whitespace"...

I didn't found anything on "copyWithoutWhitespace", do you know if there's any way to avoid that select? To treat it not as a white space, but as a delimiter?