The mouse pointer used should be the text cursor (α) one since text is selectable, not the default arrow (β) pointer.
It's the default arrow pointer that's used.
Probably correct.
I very much hope that the mouse pointer is always text cursor (α), even if no text is selected; Just like git-bash and cygwin.
Is there any way to configure a text mouse pointer is text cursor (α), ? Just like git-bash and cygwin.
Just to make sure that I'm not missing anything, there's currently no option for this, right?
@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 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.
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.
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:

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.
I actually think we should just always use α. I know that's controversial :smile:
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.
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.
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.
Most helpful comment
I actually think we should just always use α. I know that's controversial :smile: