Mouse pointer should be text and not arrow one #1935

@JushBJJ commented on GitHub (Jun 23, 2019):

#1375

@JushBJJ commented on GitHub (Jun 23, 2019): #1375

claunia commented

@DHowett-MSFT commented on GitHub (Jun 26, 2019):

Probably correct.

@DHowett-MSFT commented on GitHub (Jun 26, 2019): Probably correct.

claunia commented

@liangrongjie commented on GitHub (Aug 6, 2019):

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 commented on GitHub (Aug 6, 2019): I very much hope that the mouse pointer is always text cursor (Ꮖ), even if no text is selected; Just like git-bash and cygwin.

claunia commented

2026-01-30 22:42:23 +00:00

@liangrongjie commented on GitHub (Aug 6, 2019):

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

@liangrongjie commented on GitHub (Aug 6, 2019): Is there any way to configure a text mouse pointer is text cursor (Ꮖ), ? Just like git-bash and cygwin.

claunia commented

@matteocontrini commented on GitHub (Sep 29, 2019):

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

@matteocontrini commented on GitHub (Sep 29, 2019): Just to make sure that I'm not missing anything, there's currently no option for this, right?

claunia commented

2026-01-30 22:42:23 +00:00

@zadjii-msft commented on GitHub (Oct 2, 2019):

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

@zadjii-msft commented on GitHub (Oct 2, 2019): @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.

claunia commented

2026-01-30 22:42:23 +00:00

@warpdesign commented on GitHub (Oct 2, 2019):

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

@warpdesign commented on GitHub (Oct 2, 2019): @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.

claunia commented

@zadjii-msft commented on GitHub (Oct 2, 2019):

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.

@zadjii-msft commented on GitHub (Oct 2, 2019): 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.

claunia commented

@warpdesign commented on GitHub (Oct 2, 2019):

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:

@warpdesign commented on GitHub (Oct 2, 2019): 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: ![Capture d’écran 2019-10-02 à 18 21 25](https://user-images.githubusercontent.com/199648/66080032-8e196f80-e565-11e9-8d3e-d18079ff39dd.png) 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: ![cursor_iterm](https://user-images.githubusercontent.com/199648/66080946-61665780-e567-11e9-8027-869eff83854f.gif)

claunia commented

@matteocontrini commented on GitHub (Oct 2, 2019):

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.

@matteocontrini commented on GitHub (Oct 2, 2019): > 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.

claunia commented

@DHowett-MSFT commented on GitHub (Oct 2, 2019):

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

@DHowett-MSFT commented on GitHub (Oct 2, 2019): I actually think we should just always use Ꮖ. I know that's controversial :smile:

claunia commented

@tats-u commented on GitHub (Jan 27, 2020):

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.

@tats-u commented on GitHub (Jan 27, 2020): ConHost: Arrow [Hyper](https://hyper.is/): 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.

claunia commented

@nogweii commented on GitHub (Mar 18, 2020):

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.

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

claunia commented

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

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

claunia commented

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

Alright, https://github.com/microsoft/terminal/pull/5028

@DHowett-MSFT commented on GitHub (Mar 20, 2020): Alright, https://github.com/microsoft/terminal/pull/5028

claunia commented

@matteocontrini commented on GitHub (Nov 3, 2022):

Is there any chance for this to be implemented? Thanks

@matteocontrini commented on GitHub (Nov 3, 2022): Is there any chance for this to be implemented? Thanks

claunia commented

@zadjii-msft commented on GitHub (Nov 3, 2022):

@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!

@zadjii-msft commented on GitHub (Nov 3, 2022): @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!

claunia commented

@4wk- commented on GitHub (Mar 6, 2023):

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

@4wk- commented on GitHub (Mar 6, 2023): 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

claunia commented

@mailinglists35 commented on GitHub (Nov 19, 2023):

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.

@mailinglists35 commented on GitHub (Nov 19, 2023): > 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**.

claunia commented

@mailinglists35 commented on GitHub (Nov 19, 2023):

rant: I can't believe this isn't so obvious and I have to spend time explaining why it should work that way.

@mailinglists35 commented on GitHub (Nov 19, 2023): rant: I can't believe this isn't so obvious and I have to spend time explaining why it should work that way.

claunia commented