How to move cursor using mouse #5996

Closed
opened 2026-01-31 00:27:23 +00:00 by claunia · 24 comments
Owner

Originally created by @AmericanY on GitHub (Jan 16, 2020).

Version: 0.8.10091.0

How to move cursor using mouse ?

Originally created by @AmericanY on GitHub (Jan 16, 2020). ``` Version: 0.8.10091.0 ``` How to move cursor using `mouse` ?
claunia added the Issue-QuestionNeeds-TriageNeeds-Tag-FixNeeds-Attention labels 2026-01-31 00:27:23 +00:00
Author
Owner

@zadjii-msft commented on GitHub (Jan 16, 2020):

@AmericanY We're going to need a little more context to try and understand what your problem is. Is there a particular commandline application you're trying to use the mouse to move the cursor in? Can you reproduce your scenario in the legacy console? What would you expect to happen, and what's actually happening?

@zadjii-msft commented on GitHub (Jan 16, 2020): @AmericanY We're going to need a little more context to try and understand what your problem is. Is there a particular commandline application you're trying to use the mouse to move the cursor in? Can you reproduce your scenario in the legacy console? What would you expect to happen, and what's actually happening?
Author
Owner

@AmericanY commented on GitHub (Jan 16, 2020):

@zadjii-msft thanks for replying me back. basically I'm using windows new terminal currently. and usually i move the cursor using the Arrow keys. so i would like to know if i can move the cursor by mouse directly ?

for example

let's say i typed this command ping google.com and the cursor is in the end of the command, Now, can i move the cursor using the mouse to put it after ping for example?

@AmericanY commented on GitHub (Jan 16, 2020): @zadjii-msft thanks for replying me back. basically I'm using windows new terminal currently. and usually i move the cursor using the Arrow keys. so i would like to know if i can move the cursor by mouse directly ? for example let's say i typed this command `ping google.com` and the cursor is in the end of the command, Now, can i move the cursor using the mouse to put it after `ping` for example?
Author
Owner

@zadjii-msft commented on GitHub (Jan 16, 2020):

No, that's not something that won't work without cooperation of the commandline application that's running in the Terminal. For example, bash or cmd.exe. Those are the applications that are actually responsible for drawing the prompt and the input line. They would need to be modified to support clicking to set the cursor position. I'm not sure I know of any shell application that actually supports that tbh. You can confirm this by trying to run the equivalent commandline in a legacy console window - note that that mouse doesn't work like that in shells there either.

vim is a classic example of a application that is mouse aware. It currently doesn't work in the terminal because of #376 and #545.

@zadjii-msft commented on GitHub (Jan 16, 2020): No, that's not something that won't work without cooperation of the commandline application that's running in the Terminal. For example, `bash` or `cmd.exe`. Those are the applications that are actually responsible for drawing the prompt and the input line. They would need to be modified to support clicking to set the cursor position. I'm not sure I know of _any_ shell application that actually supports that tbh. You can confirm this by trying to run the equivalent commandline in a legacy console window - note that that mouse doesn't work like that in shells there either. `vim` is a classic example of a application that _is_ mouse aware. It currently doesn't work in the terminal because of #376 and #545.
Author
Owner

@ghost commented on GitHub (Jan 20, 2020):

This issue has been automatically marked as stale because it has been marked as requiring author feedback but has not had any activity for 4 days. It will be closed if no further activity occurs within 3 days of this comment.

@ghost commented on GitHub (Jan 20, 2020): This issue has been automatically marked as stale because it has been marked as requiring author feedback but has not had any activity for **4 days**. It will be closed if no further activity occurs **within 3 days of this comment**.
Author
Owner

@RomeshA commented on GitHub (May 14, 2020):

Personally I think this would be a nice feature to have, just to note in regard to @zadjii-msft's comment regarding applications that support this, the Mac OS terminal app provides exactly this functionality (see https://support.apple.com/en-au/guide/terminal/trmlshtcts/mac under action 'Reposition the insertion point', basically Option+Click repositions the cursor)

@RomeshA commented on GitHub (May 14, 2020): Personally I think this would be a nice feature to have, just to note in regard to @zadjii-msft's comment regarding applications that support this, the Mac OS terminal app provides exactly this functionality (see https://support.apple.com/en-au/guide/terminal/trmlshtcts/mac under action 'Reposition the insertion point', basically Option+Click repositions the cursor)
Author
Owner

@zadjii-msft commented on GitHub (May 14, 2020):

I'd be curious how that works from a technical point of view. Do they just like, send left/right arrow key presses to emulate moving the cursor as if it was done on the keyboard when the user clicks? Or is there tighter integration with the shell that's running? Does this work in all shells in Terminal.app? Or is this a zsh-specific feature?

@zadjii-msft commented on GitHub (May 14, 2020): I'd be curious _how_ that works from a technical point of view. Do they just like, send left/right arrow key presses to emulate moving the cursor as if it was done on the keyboard when the user clicks? Or is there tighter integration with the shell that's running? Does this work in _all_ shells in Terminal.app? Or is this a `zsh`-specific feature?
Author
Owner

@RomeshA commented on GitHub (May 15, 2020):

Not sure, but it could be something like the former, because it seems to work when I just tried it with zsh, bash and also csh. I wouldn't be surprised if there are edge cases where it doesn't reposition correctly, but my experience is similar to @AmericanY in that 99% of the time I would use that feature to edit something in the middle of a long command, and it seems to work fine for that

I dug a little deeper though and it seems like this is revisiting a discussion from a few years ago in VS Code - https://github.com/microsoft/vscode/issues/26401. It looks like they settled on an implementation based on sending key presses (https://github.com/microsoft/vscode/issues/44448) and I can confirm that the latest VS Code on Windows 10 supports moving the cursor in the integrated terminal using Alt+Click. So it would be great to match this functionality in Windows Terminal

@RomeshA commented on GitHub (May 15, 2020): Not sure, but it could be something like the former, because it seems to work when I just tried it with `zsh`, `bash` and also `csh`. I wouldn't be surprised if there are edge cases where it doesn't reposition correctly, but my experience is similar to @AmericanY in that 99% of the time I would use that feature to edit something in the middle of a long command, and it seems to work fine for that I dug a little deeper though and it seems like this is revisiting a discussion from a few years ago in VS Code - https://github.com/microsoft/vscode/issues/26401. It looks like they settled on an implementation based on sending key presses (https://github.com/microsoft/vscode/issues/44448) and I can confirm that the latest VS Code on Windows 10 supports moving the cursor in the integrated terminal using Alt+Click. So it would be great to match this functionality in Windows Terminal
Author
Owner

@AmericanY commented on GitHub (May 15, 2020):

@RomeshA that's it ! Yes, i hope that windows new terminal can give us this feature as it's really really helpful at all

@AmericanY commented on GitHub (May 15, 2020): @RomeshA that's it ! Yes, i hope that windows new terminal can give us this feature as it's really really helpful at all
Author
Owner

@AmericanY commented on GitHub (May 15, 2020):

BTW, i just checked and i can see that mouse is not performing normally over SSH connection. I tried to use it within vim over SSH and within htop and i see the terminal receive the click's wrongly .

@AmericanY commented on GitHub (May 15, 2020): BTW, i just checked and i can see that mouse is not performing normally over SSH connection. I tried to use it within vim over SSH and within htop and i see the terminal receive the click's wrongly .
Author
Owner

@mornir commented on GitHub (May 28, 2020):

Came here after seeing this tweet where it works in zsh:
https://twitter.com/leonte_dev/status/1264140864751878144
(don't want to be a caveman anymore 🤪)

@mornir commented on GitHub (May 28, 2020): Came here after seeing this tweet where it works in zsh: https://twitter.com/leonte_dev/status/1264140864751878144 (don't want to be a caveman anymore 🤪)
Author
Owner

@trystkelly commented on GitHub (May 5, 2021):

Hi, I have a dumb question. What is it that makes this especially hard? Like, we can already select text with the mouse, so why not just move the cursor to where you select, like text fields in other programs? Even in programs like notepad, you can click with the mouse, and I'm guessing it's not implemented by spamming fake arrow key presses. I guess I just don't understand why the text editor in terminals is so different from text fields in almost every other program. You can't even delete mouse-selected text with backspace, so it's apparently different from arrow-selected text for some reason.

@trystkelly commented on GitHub (May 5, 2021): Hi, I have a dumb question. What is it that makes this especially hard? Like, we can already select text with the mouse, so why not just move the cursor to where you select, like text fields in other programs? Even in programs like notepad, you can click with the mouse, and I'm guessing it's not implemented by spamming fake arrow key presses. I guess I just don't understand why the text editor in terminals is so different from text fields in almost every other program. You can't even delete mouse-selected text with backspace, so it's apparently different from arrow-selected text for some reason.
Author
Owner

@zadjii-msft commented on GitHub (May 5, 2021):

Fundamentally, it's because there's two different applications running. The terminal (e.g. Windows Terminal, gnome-terminal, xterm, iTerm2, etc), and the client (cmd, powershell, bash, vim, tmux, etc).

  • The terminal is responsible for drawing the window and receiving input
  • the client is responsible for processing that input and emitting text for the terminal to display.

Client apps can tell the terminal to move the cursor to a specific location. However, the Terminal can only tell a client "The user clicked here". It's up to each underlying client application to be able to understand such a message from the terminal. The client has to be able to ask the terminal to enable mouse reporting, then parse the input for mouse sequences, and reverse-engineer where the prompt is in the viewport, make sure the mouse is in that line, and move their own internal representation of the cursor to that position. That's obviously a lot more work than just "append the input character to the end of the prompt" 😄. Most shells don't do this, but things like vim do.

@zadjii-msft commented on GitHub (May 5, 2021): Fundamentally, it's because there's two different applications running. The terminal (e.g. Windows Terminal, gnome-terminal, xterm, iTerm2, etc), and the client (`cmd`, `powershell`, `bash`, `vim`, `tmux`, etc). * The terminal is responsible for drawing the window and receiving input * the client is responsible for processing that input and emitting text for the terminal to display. Client apps can tell the terminal to move the cursor to a specific location. However, the Terminal can only tell a client "The user clicked here". It's up to each underlying client application to be able to understand such a message from the terminal. The client has to be able to ask the terminal to enable mouse reporting, then parse the input for mouse sequences, and reverse-engineer where the prompt is in the viewport, make sure the mouse is in that line, and move their own internal representation of the cursor to that position. That's obviously a lot more work than just "append the input character to the end of the prompt" 😄. Most shells don't do this, but things like `vim` do.
Author
Owner

@trystkelly commented on GitHub (May 5, 2021):

Oh, I see! Thanks a lot for your fast answer!
I'm surprised to hear the client even has a notion of the cursor; my intuition was that it just took in raw "finished" text commands, and the terminal can have whatever interface it wants for editing that before sending it. Yeah that does sound pretty challenging! I guess this is part of the old computer history leaking through to today

@trystkelly commented on GitHub (May 5, 2021): Oh, I see! Thanks a lot for your fast answer! I'm surprised to hear the client even has a notion of the cursor; my intuition was that it just took in raw "finished" text commands, and the terminal can have whatever interface it wants for editing that before sending it. Yeah that does sound pretty challenging! I guess this is part of the old computer history leaking through to today
Author
Owner

@crosbyc2 commented on GitHub (Jun 17, 2021):

I know this is available in iTerm2. In editors and on the command line I can do ⌘ + click and the cursor will move where the mouse pointer is.

@crosbyc2 commented on GitHub (Jun 17, 2021): I know this is available in iTerm2. In editors and on the command line I can do ` ⌘ + click` and the cursor will move where the mouse pointer is.
Author
Owner

@IanKemp commented on GitHub (Jul 23, 2021):

the client is responsible for processing that input and emitting text for the terminal to display.

I disagree with this. If the client is aware of said input type then yes, but if the client is not then it should IMO be the terminal's job to translate the types of input that specific client doesn't understand, into input types it can. In the case of cmd for example, which doesn't understand mouse clicks (except for very specific scenarios), the terminal should translate mouse clicks into the appropriate keystrokes and transmit them back to cmd - much like VS Code.

Since a terminal already has to have client-specific behaviour to accommodate for the vagaries of said clients, adding an additional layer for mapping for mouse clicks => keystrokes doesn't seem like a massive ask. The implementation of such a mapping layer on a per-client basis, however, is likely to be non-trivial.

@IanKemp commented on GitHub (Jul 23, 2021): > the client is responsible for processing that input and emitting text for the terminal to display. I disagree with this. If the client is aware of said input type then yes, but if the client is not then it should IMO be the terminal's job to translate the types of input that specific client doesn't understand, into input types it can. In the case of `cmd` for example, which doesn't understand mouse clicks (except for very specific scenarios), the terminal should translate mouse clicks into the appropriate keystrokes and transmit them back to `cmd` - much like VS Code. Since a terminal already has to have client-specific behaviour to accommodate for the vagaries of said clients, adding an additional layer for mapping for mouse clicks => keystrokes doesn't seem like a massive ask. The *implementation* of such a mapping layer on a per-client basis, however, is likely to be non-trivial.
Author
Owner

@qosobrin commented on GitHub (Aug 24, 2021):

So, @zadjii-msft , could you elaborate your answer a little bit more?

No, that's not something that won't work without cooperation of the commandline application that's running in the Terminal. For example, bash or cmd.exe. Those are the applications that are actually responsible for drawing the prompt and the input line.

In PowerShell ISE I can change the entry point just by clicking the mouse, something that I can not do in Windows Terminal. That feature is a must-have for me to use WT.

Regards.

@qosobrin commented on GitHub (Aug 24, 2021): So, @zadjii-msft , could you elaborate your answer a little bit more? > No, that's not something that won't work without cooperation of the commandline application that's running in the Terminal. For example, `bash` or `cmd.exe`. Those are the applications that are actually responsible for drawing the prompt and the input line. In PowerShell ISE I can change the entry point just by clicking the mouse, something that I can not do in Windows Terminal. That feature is a must-have for me to use WT. Regards.
Author
Owner

@jwhite007 commented on GitHub (Nov 9, 2021):

WSLTTY (https://github.com/mintty/wsltty) for wsl terminal implements this very well. The cursor can be at the end of " line of text|", and I can move it to " line of| text" with just a simple mouse click. Easy Peasy, Nice and Pleasey. That is a wsltty thing and not a shell or application thing as the same functionality is not present when I open up the default wsl terminal.

@jwhite007 commented on GitHub (Nov 9, 2021): WSLTTY (https://github.com/mintty/wsltty) for wsl terminal implements this very well. The cursor can be at the end of "$ line of text|", and I can move it to "$ line of| text" with just a simple mouse click. Easy Peasy, Nice and Pleasey. That is a wsltty thing and not a shell or application thing as the same functionality is not present when I open up the default wsl terminal.
Author
Owner

@zadjii-msft commented on GitHub (Nov 15, 2021):

We've actually had a lot more discussion on the technical aspects of how to implement this over at #8573.

@zadjii-msft commented on GitHub (Nov 15, 2021): We've actually had a _lot_ more discussion on the technical aspects of how to implement this over at #8573.
Author
Owner

@jwhite007 commented on GitHub (Nov 15, 2021):

@zadjii-msft, Yes, thank you. I actually noticed the link to #8573 from sosnik after I had posted my comment.

@jwhite007 commented on GitHub (Nov 15, 2021): @zadjii-msft, Yes, thank you. I actually noticed the link to #8573 from sosnik after I had posted my comment.
Author
Owner

@con-dog commented on GitHub (Jan 11, 2022):

@zadjii-msft is moving the cursor with the 'Mouse-Click + key' ever going to be implemented in Windows Terminal?

In Visual Studio Code there is support for 'Alt + Mouse-click' to rapidly move the cursor. The cursor turns into a crosshair. I have tested this with Bash, Python, and CMD! So surely it should be possible to do and bring in?

I love Windows Terminal and would be so happy to have this feature for CLI apps

@con-dog commented on GitHub (Jan 11, 2022): @zadjii-msft is moving the cursor with the 'Mouse-Click + key' ever going to be implemented in Windows Terminal? In Visual Studio Code there is support for 'Alt + Mouse-click' to rapidly move the cursor. The cursor turns into a crosshair. I have tested this with Bash, Python, and CMD! So surely it should be possible to do and bring in? I love Windows Terminal and would be so happy to have this feature for CLI apps
Author
Owner

@zadjii-msft commented on GitHub (Jan 11, 2022):

@con-dog If we can ever come up with a sufficient design with minimal edge cases, then sure! There's a LOT of discussion in #8573 on this topic, covering the intimate implementation details. Might shed some light on why this hasn't landed yet.

@zadjii-msft commented on GitHub (Jan 11, 2022): @con-dog If we can ever come up with a sufficient design with minimal edge cases, then sure! There's a LOT of discussion in #8573 on this topic, covering the intimate implementation details. Might shed some light on why this hasn't landed yet.
Author
Owner

@Suncatcher commented on GitHub (Jun 22, 2022):

In Visual Studio Code there is support for 'Alt + Mouse-click' to rapidly move the cursor. The cursor turns into a crosshair. I have tested this with Bash, Python, and CMD! So surely it should be possible to do and bring in?

Agree. If this was implemented in VSCode which is MS ecosystem, shy the hell it cannot be implemented in Terminal?

@Suncatcher commented on GitHub (Jun 22, 2022): > In Visual Studio Code there is support for 'Alt + Mouse-click' to rapidly move the cursor. The cursor turns into a crosshair. I have tested this with Bash, Python, and CMD! So surely it should be possible to do and bring in? Agree. If this was implemented in VSCode which is MS ecosystem, shy the hell it cannot be implemented in Terminal?
Author
Owner

@pr8x commented on GitHub (Jan 11, 2025):

Why is this issue closed?! Very annoying that a bot randomly closes issues when they don't receive immediate attention. This is one way to keep the "backlog" clean by pretending issues don't exist.

@pr8x commented on GitHub (Jan 11, 2025): Why is this issue closed?! Very annoying that a bot randomly closes issues when they don't receive immediate attention. This is one way to keep the "backlog" clean by pretending issues don't exist.
Author
Owner

@zadjii-msft commented on GitHub (Jan 11, 2025):

@pr8x

We've actually had a lot more discussion on the technical aspects of how to implement this over at #8573.

You should go read that linked thread.

@zadjii-msft commented on GitHub (Jan 11, 2025): @pr8x > We've actually had a _lot_ more discussion on the technical aspects of how to implement this over at [#8573](https://github.com/microsoft/terminal/issues/8573). You should go read that linked thread.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/terminal#5996