Mouse pointer should be text and not arrow one

[warpdesign]

Expected behavior

The mouse pointer used should be the text cursor (Ꮖ) one since text is selectable, not the default arrow (↖) pointer.

Actual behavior

It's the default arrow pointer that's used.

[JushBJJ]

#1375

[DHowett-MSFT]

Probably correct.

[liangrongjie]

I very much hope that the mouse pointer is always text cursor (Ꮖ), even if no text is selected; Just like git-bash and cygwin.

[liangrongjie]

Is there any way to configure a text mouse pointer is text cursor (Ꮖ), ? Just like git-bash and cygwin.

[matteocontrini]

Just to make sure that I'm not missing anything, there's currently no option for this, right?

[zadjii-msft]

@matteocontrini You're not missing anything. This is not currently a possible setting. We'd welcome a community contribution to add this as a setting, but for now, it will remain on the backlog.

[warpdesign]

@zadjii-msft I understand this is not the priority right now but I think this should really be implemented like this, and not as an option. Just like there is no option in Word or Edge to disable the text cursor when an input/text area is active or the mouse is over some selectable text.

If I remember correctly, in very old cmd.exe by default it wasn't possible to select text: you had to choose an option in a menu to enter this mode. So this made sense the pointer wasn't the text one by default. But in the new Terminal app, this is no longer the case: you may always select text and the mouse cursor should hint at that.

[zadjii-msft]

I strongly disagree, with two points.

One of the things we really want to push with the Terminal is customizability. Some people might not want a Ꮖ cursor. I certainly don't. Making things optional, especially things that are easily changed like this, makes the broadest number of users happy. Sure we could make the text cursor the default, but lets let people change it back :)

Secondly, when I think of a text Ꮖ cursor, that makes me think that I can click somewhere and use that to move the cursor to the clicked location. In Word and office applications, that click does move the visible cursor. In browsers, there might not always be a visible cursor, but when you click on text, it does leave a hidden cursor in that location, that can be used for mouse selection. However, in general when using the Terminal, clicking does not move the cursor. Sure, in something like vim, clicking can move the cursor, but as a shell prompt, clicking is not going to move the cursor within the prompt. Scrolling through logs, a click is not going to move the active text insertion position into another place in the buffer. That's what the Ꮖ cursor makes me really think, and that's what won't happen in the Terminal.

[warpdesign]

No problem having an option for that but I still think that by default it should be consistent with the whole OS & apps. And whenever text is selectable, you shouldn't have an "↖" mouse pointer but a text "Ꮖ" pointer.

Scrolling through logs, a click is not going to move the active text insertion position into another place in the buffer. That's what the Ꮖ cursor makes me really think, and that's what won't happen in the Terminal.

I'm fine with that. Having a text mouse pointer and clicking somewhere doesn't necessarily mean that you are changing the active insertion position simply because you may have an area with selectable text that's simply not editable, so there won't be any active insertion position. Think about a webpage, a pdf reader, the about window of Windows 10 Calculator app, etc... There are lots of text that's selectable but cannot be edited and the user needs to know about it. In modern interfaces (that includes Windows apps, like Settings,...), when you hover text that's selectable, the mouse pointer switches to "Ꮖ". I don't see why this should be different for the Terminal app.

Here is the Windows Settings app:

I selected some text that's selectable, and it correctly uses the "Ꮖ" mouse pointer. But if I move the mouse over Your device recently got the latest update... on the right, the mouse pointer would turn into "↖", showing that this text cannot be selected/copied.

Here is an example of a Mac terminal app: selecting text doesn't change the insert position:

[matteocontrini]

Here is an example of a Mac terminal app: selecting text doesn't change the insert position:

This is also the case on the default Ubuntu terminal, and probably many other distributions. The Windows cmd/wt is probably one of the few terminals to behave differently.

[DHowett-MSFT]

I actually think we should just always use Ꮖ. I know that's controversial 😄

[tats-u]

ConHost: Arrow
Hyper: Arrow
Tera Term: Text
PuTTY: Text
GNOME Terminal: Text
Konsole: presumably Text (according to a screen-capture movie)
Xterm: Text

You can refer to this.

[nogweii]

One thing to consider when designing this is that many Linux terminals will actually switch to using an arrow when the terminal app registers mouse support. You can see this when enabling Vim's mouse support, for instance.

[DHowett]

Alright, I implemented this and i realized i hate it. I can't select text any more because I keep ending up off-by-one on the start point. It looks like it should be easy, but the point projected off the I-beam cursor doesn't line up with the completely normal terminal grid.

[DHowett-MSFT]

Alright, #5028

[matteocontrini]

Is there any chance for this to be implemented? Thanks

[zadjii-msft]

@matteocontrini not any time immediately soon. There was an attempt in #5028, but we ran into some fundamental issues with WinUI that prevented us from getting that across the finish line. We were under the impression that this wouldn't be a solvable problem before WinUI 3 (which we're not likely to move to any time soon).

I'd LOVE to see someone take that branch and prove me wrong!

[4wk-]

I also would love the Ꮖ cursor to be set by default, but yeah an option is the better way here to let users decide. I don't have the skill to do this, unfortunately; but that's one of the time I wish Github could allow user to put bounties on tasks 😄 to attract more contributors and help @DHowett attempt! Cheers

[mailinglists35]

One thing to consider when designing this is that many Linux terminals will actually switch to using an arrow when the terminal app registers mouse support. You can see this when enabling Vim's mouse support, for instance.

This is one of the strongest arguments

When the underlying console app DOES have mouse support, it signals the terminal (I don't know how it happens behind the scenes) and the terminal CHANGES the cursor from I-beam pointer to OS/DE defined arrow pointer. This in turn signals the user that it can or can not freely type into the area where the mouse is an arrow, or more exactly the user knows that when the cursor is arrow, the key presses are NOT sent ad-literam to the app, but instead at most they can be interpreted as command shortcuts to the app.

This UI convention has existed for years, I think even since Windows 3.11: programs that work with text input are responsible for changing the mouse cursor from arrow to I-beam when mouse is hovering or moving over the text input area. The only other case when the mouse cursor is changed from arrow to I-beam is when there is selectable text available, even if the text input is not available.

Windows Terminal should make no exception from this convention and has no reason not to: it's an app that has 90%+ of its area working with text, both input and selectable. Additionally, when the app running inside the terminal signals that it has full mouse support, it MUST change the cursor from I-beam to arrow.

Sure it can be argumented "it's overly complicated at this stage", but this should be a clearly declared goal of the app. Not "hm, it's debatable, hm, oh it's so complicated technically that we might just let it low in the priority queue".

This should be among top priority tasks for a Terminal app.

[zadjii-msft]

There's no debate as to if we should do this or not. For those who read the thread, as I mentioned before (#1441 (comment)), we tried to do this a couple years back (in #5028), and ran into fundamental flaws in WinUI. We'd love if someone could prove us wrong though!