Allow mouse clicks to reposition cursor by emitting cursor key sequences #11788

@skyline75489 commented on GitHub (Dec 14, 2020):

In Terminal.app & iTerm2 on macOS, you can hold down option while clicking to jump in the prompt line. I just found out this and I think this is actually a helpful feature.

@sosnik I appreciate the effort for mentioning the implementation of mintty. But due to the licensing difference(WT being MIT and mintty being GPL), it is not legal or ethical for us to use the actual code of GPL-licensed projects. Still I like the feature. I'd like this added to the backlog.

@skyline75489 commented on GitHub (Dec 14, 2020): In Terminal.app & iTerm2 on macOS, you can hold down <kbd>option</kbd> while clicking to jump in the prompt line. I just found out this and I think this is actually a helpful feature. @sosnik I appreciate the effort for mentioning the implementation of mintty. But due to the licensing difference(WT being MIT and mintty being GPL), it is not legal or ethical for us to use the actual code of GPL-licensed projects. Still I like the feature. I'd like this added to the backlog.

claunia commented

@sosnik commented on GitHub (Dec 14, 2020):

I appreciate the effort for mentioning the implementation of mintty. But due to the licensing difference(WT being MIT and mintty being GPL), it is not legal or ethical for us to use the actual code of GPL-licensed projects.

I understand the legal and ethical limitations. I merely wanted to point out the mintty implementation as proof that 'it can be done'.

Nevertheless, let's see what comes of it. I use a mixture of keyboard and mouse for terminal navigation (sometimes mouse is just more convenient when you're using it with a screen magnifier).

@sosnik commented on GitHub (Dec 14, 2020): > I appreciate the effort for mentioning the implementation of mintty. But due to the licensing difference(WT being MIT and mintty being GPL), it is not legal or ethical for us to use the actual code of GPL-licensed projects. I understand the legal and ethical limitations. I merely wanted to point out the mintty implementation as proof that 'it can be done'. Nevertheless, let's see what comes of it. I use a mixture of keyboard and mouse for terminal navigation (sometimes mouse is just more convenient when you're using it with a screen magnifier).

claunia commented

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

Ah okay. So this still isn't a shell feature, it's a terminal one. Glad I wasn't totally off base in #4268.

I'll keep this open to be the "add a setting to allow mouse clicks to send arrow keypresses issue". It's a bit of a wonky setting (IMO), but hey there's prior art we can use for it. I'd wonder how this would interact with something like vim's visual selection mode with the mouse.

I'd probably end up sticking this under the experimental. namespace, mostly because "this may not work the way you'd expect"

@zadjii-msft commented on GitHub (Dec 14, 2020): Ah okay. So this still isn't a _shell_ feature, it's a _terminal_ one. Glad I wasn't totally off base in #4268. I'll keep this open to be the "add a setting to allow mouse clicks to send arrow keypresses issue". It's a bit of a wonky setting (IMO), but hey there's prior art we can use for it. I'd wonder how this would interact with something like `vim`'s visual selection mode with the mouse. I'd probably end up sticking this under the `experimental.` namespace, mostly because "this may not work the way you'd expect"

claunia commented

2026-01-31 02:57:27 +00:00

@malxau commented on GitHub (Dec 15, 2020):

I'm really curious how this works. Using mintty in git bash, I can see that the mouse click can move the cursor across lines (which blows my mind.) When we'd spoken about this before, the big question I had is how to decide when to emit vertical cursor keys vs. assume a line has wrapped and emit many more horizontal keys. The "correct" answer is application dependent. (Is readline handling mouse clicks itself for this?)

Using SSH so I can have Win32 console processes under mintty, the experience degrades somewhat, because the mouse click can only move the cursor along the same line that it's currently on. It's clearly trying to guess the number of keystrokes to emit and send them to the application though - I used tabs so when it calculated the number of cells to move it didn't match the number of characters seen by the application, and the cursor moved to the wrong place.

@malxau commented on GitHub (Dec 15, 2020): I'm really curious how this works. Using mintty in git bash, I can see that the mouse click can move the cursor across lines (which blows my mind.) When we'd spoken about this before, the big question I had is how to decide when to emit vertical cursor keys vs. assume a line has wrapped and emit many more horizontal keys. The "correct" answer is application dependent. (Is readline handling mouse clicks itself for this?) Using SSH so I can have Win32 console processes under mintty, the experience degrades somewhat, because the mouse click can only move the cursor along the same line that it's currently on. It's clearly trying to guess the number of keystrokes to emit and send them to the application though - I used tabs so when it calculated the number of cells to move it didn't match the number of characters seen by the application, and the cursor moved to the wrong place.

claunia commented

@DHowett commented on GitHub (Dec 15, 2020):

Yeah, I am deeply conflicted about this feature. Cool and magical when it works, “something is a bit off” when it doesn’t.

Also, can’t msys2 host win32 processes natively now? They added ConPTY support recently. Why use SSH for that? This may warrant a side thread.

@DHowett commented on GitHub (Dec 15, 2020): Yeah, I am deeply conflicted about this feature. Cool and magical when it works, “something is a bit off” when it doesn’t. Also, can’t msys2 host win32 processes natively now? They added ConPTY support recently. Why use SSH for that? This may warrant a side thread.

claunia commented

2026-01-31 02:57:27 +00:00

@malxau commented on GitHub (Dec 15, 2020):

@DHowett My fault, I was using an old version of Git for Windows that I had lying around. Using the current version and enabling ConPTY during setup means I don't need to SSH. Without SSH though, results are the same - it only emits keystrokes for navigating around the current line.

@malxau commented on GitHub (Dec 15, 2020): @DHowett My fault, I was using an old version of Git for Windows that I had lying around. Using the current version and enabling ConPTY during setup means I don't need to SSH. Without SSH though, results are the same - it only emits keystrokes for navigating around the current line.

claunia commented

2026-01-31 02:57:27 +00:00

@sosnik commented on GitHub (Dec 15, 2020):

mintty manages to incorporate a lot of mouse support indeed. It also intercepts scroll events and will scroll within a console window (like more or man) instead of scrolling the terminal output (current behaviour with Windows Terminal). However there are some variations in how interactive console applications are handled by mintty and applications running with it. For instance, cygwin running in mintty works with nodejs repl, msys2 running under mintty doesn't, but msys2 running under Windows Terminal does.

There are probably different builds of mintty at work, and perhaps some custom interactions with the shell/rest of the system.

I'd wonder how this would interact with something like vim's visual selection mode

I haven't had occasion to use it before, vim is one place where I'm fully keyboard-based.

@sosnik commented on GitHub (Dec 15, 2020): mintty manages to incorporate a lot of mouse support indeed. It also intercepts scroll events and will scroll within a console window (like `more` or `man`) instead of scrolling the terminal output (current behaviour with Windows Terminal). However there are some variations in how interactive console applications are handled by mintty and applications running with it. For instance, cygwin running in mintty works with nodejs repl, msys2 running under mintty doesn't, but msys2 running under Windows Terminal does. There are probably different builds of mintty at work, and perhaps some custom interactions with the shell/rest of the system. > I'd wonder how this would interact with something like vim's visual selection mode I haven't had occasion to use it before, vim is one place where I'm fully keyboard-based.

claunia commented

@DHowett commented on GitHub (Dec 15, 2020):

intercepts scroll events

at least that one is standardized and an application requests it via DECSET.

@DHowett commented on GitHub (Dec 15, 2020): > intercepts scroll events at least that one is standardized and an application requests it via `DECSET`.

claunia commented

@dkaloc commented on GitHub (Jan 21, 2021):

Hi.

Not sure how much relevant this is, but I wrote some tiny shell scripts implementing placing the CLI text cursor on mouse clicks for Zsh running in an xterm-compatible terminal.

The solution is yet undocumented (sorry for that :-)) and kind of brute-force, but as an exchange, you get a script supporting multiline, glyphs of variable widths and prompts (left and right) of any complexities.

Usage. If you are a Prezto user, do the following:

Enable additional module locations:

# Add additional directories to load prezto modules from
zstyle ':prezto:load' pmodule-dirs $HOME/.zprezto-contrib

Download the 'mouse-toolkit' module:

mkdir $HOME/.zprezto-contrib/mouse-toolkit && \
curl https://raw.githubusercontent.com/dkaloc/misc/main/mouse-toolkit.zsh > $HOME/.zprezto-contrib/mouse-toolkit/init.zsh && \
chmod o+x $HOME/.zprezto-contrib/mouse-toolkit/init.zsh

Download the 'zle-cursor-placement' module:

mkdir $HOME/.zprezto-contrib/zle-cursor-placement && \
curl https://raw.githubusercontent.com/dkaloc/misc/main/zle-cursor-placement.zsh > $HOME/.zprezto-contrib/zle-cursor-placement/init.zsh && \
chmod o+x $HOME/.zprezto-contrib/zle-cursor-placement/init.zsh

Enable and configure the modules in your zpreztorc.

...
# Set the Prezto modules to load (browse modules).
# The order matters.
zstyle ':prezto:load' pmodule \
  ... \
  'mouse-toolkit' \
  'zle-cursor-placement'
...
#
# Mouse Toolkit
#
zstyle ':prezto:module:mouse-toolkit' zle-mouse-mode 'buttons-only'
zstyle ':prezto:module:mouse-toolkit' capture-mouse-in-zle 'yes'
...

And finally, make use of these modules by appending this to your zshrc:

###########################################################################
########### PLACE CURSOR on MOUSE CLICK ###################################
###########################################################################

_place-cursor-on-mouse-click() {
  ((MOUSE_TOOLKIT_BUTTON == 1)) && \
    zle zle-cursor-placement-place-cursor-to-cell \
      $MOUSE_TOOLKIT_COLUMN \
      $MOUSE_TOOLKIT_ROW
}
zle -N _place-cursor-on-mouse-click

mouse_toolkit_add_handler \
  $MOUSE_TOOLKIT_EVENT_BUTTON_CLICKED _place-cursor-on-mouse-click

Cheers,
Dusan

PS: Tried hard to also support bash and fish shells, but unfortunately they lack the right tools in their shell program-facing APIs.

@dkaloc commented on GitHub (Jan 21, 2021): Hi. Not sure how much relevant this is, but I wrote some tiny shell scripts implementing placing the CLI text cursor on mouse clicks for Zsh running in an xterm-compatible terminal. The solution is yet undocumented (sorry for that :-)) and kind of brute-force, but as an exchange, you get a script supporting multiline, glyphs of variable widths and prompts (left and right) of any complexities. Usage. If you are a Prezto user, do the following: 1. Enable additional module locations: ``` # Add additional directories to load prezto modules from zstyle ':prezto:load' pmodule-dirs $HOME/.zprezto-contrib ``` 2. Download the 'mouse-toolkit' module: ``` mkdir $HOME/.zprezto-contrib/mouse-toolkit && \ curl https://raw.githubusercontent.com/dkaloc/misc/main/mouse-toolkit.zsh > $HOME/.zprezto-contrib/mouse-toolkit/init.zsh && \ chmod o+x $HOME/.zprezto-contrib/mouse-toolkit/init.zsh ``` 3. Download the 'zle-cursor-placement' module: ``` mkdir $HOME/.zprezto-contrib/zle-cursor-placement && \ curl https://raw.githubusercontent.com/dkaloc/misc/main/zle-cursor-placement.zsh > $HOME/.zprezto-contrib/zle-cursor-placement/init.zsh && \ chmod o+x $HOME/.zprezto-contrib/zle-cursor-placement/init.zsh ``` 4. Enable and configure the modules in your zpreztorc. ``` ... # Set the Prezto modules to load (browse modules). # The order matters. zstyle ':prezto:load' pmodule \ ... \ 'mouse-toolkit' \ 'zle-cursor-placement' ... # # Mouse Toolkit # zstyle ':prezto:module:mouse-toolkit' zle-mouse-mode 'buttons-only' zstyle ':prezto:module:mouse-toolkit' capture-mouse-in-zle 'yes' ... ``` 5. And finally, make use of these modules by appending this to your zshrc: ``` ########################################################################### ########### PLACE CURSOR on MOUSE CLICK ################################### ########################################################################### _place-cursor-on-mouse-click() { ((MOUSE_TOOLKIT_BUTTON == 1)) && \ zle zle-cursor-placement-place-cursor-to-cell \ $MOUSE_TOOLKIT_COLUMN \ $MOUSE_TOOLKIT_ROW } zle -N _place-cursor-on-mouse-click mouse_toolkit_add_handler \ $MOUSE_TOOLKIT_EVENT_BUTTON_CLICKED _place-cursor-on-mouse-click ``` Cheers, Dusan PS: Tried hard to also support bash and fish shells, but unfortunately they lack the right tools in their shell program-facing APIs.

claunia commented

@dkaloc commented on GitHub (Jan 21, 2021):

Forgot to mention that the code "steals" your mouse when ZLE is active.

But if it doesn't work for you (and I guess it doesn't), then set the capture-mouse-in-zle to 'no' and:

Define some "mouse enablers". For example:

_enable-mouse-for-placing-cursor() {
  mouse_toolkit_enable_sgr_encoded_buttons_only_mode
  zle mouse-toolkit-start-listening-to-sgr-encoded-events-in-zle
}
zle -N _enable-mouse-for-placing-cursor

_disable-mouse-for-placing-cursor() {
  zle mouse-toolkit-stop-listening-to-sgr-encoded-events-in-zle
  mouse_toolkit_disable_sgr_encoded_buttons_only_mode
}
zle -N _disable-mouse-for-placing-cursor

And bind them to some key sequences:

bindkey '^M' _enable-mouse-for-placing-cursor
bindkey '^m' _disable-mouse-for-placing-cursor

[optional] But best combined with some AutoHotkey script. For example:

#If WinActive("ahk_exe WindowsTerminal.exe")

^LButton::
BlockInput On
SendInput ^[:M ; bindkey '^[:M' _enable-mouse-for-placing-cursor
SendEvent {Click}
SendInput ^[:m ; bindkey '^[:m' _disable-mouse-for-placing-cursor
BlockInput Off
return

#If

@dkaloc commented on GitHub (Jan 21, 2021): Forgot to mention that the code "steals" your mouse when ZLE is active. But if it doesn't work for you (and I guess it doesn't), then set the `capture-mouse-in-zle` to `'no'` and: 1. Define some "mouse enablers". For example: ``` _enable-mouse-for-placing-cursor() { mouse_toolkit_enable_sgr_encoded_buttons_only_mode zle mouse-toolkit-start-listening-to-sgr-encoded-events-in-zle } zle -N _enable-mouse-for-placing-cursor _disable-mouse-for-placing-cursor() { zle mouse-toolkit-stop-listening-to-sgr-encoded-events-in-zle mouse_toolkit_disable_sgr_encoded_buttons_only_mode } zle -N _disable-mouse-for-placing-cursor ``` 2. And bind them to some key sequences: ``` bindkey '^M' _enable-mouse-for-placing-cursor bindkey '^m' _disable-mouse-for-placing-cursor ``` 3. [optional] But best combined with some AutoHotkey script. For example: ``` #If WinActive("ahk_exe WindowsTerminal.exe") ^LButton:: BlockInput On SendInput ^[:M ; bindkey '^[:M' _enable-mouse-for-placing-cursor SendEvent {Click} SendInput ^[:m ; bindkey '^[:m' _disable-mouse-for-placing-cursor BlockInput Off return #If ```

claunia commented

2026-01-31 02:57:29 +00:00

@christianparpart commented on GitHub (Sep 14, 2021):

After reading through almost all of this, because i initially also liked that idea and considered implementing it on my end too, i now think it is absolutely wrong to implement that on the terminal emulator end.

That is what the mouse reporting protocols are there for and it is the applications duty to make use of them instead of having the terminal emulator trying to brute force through them. I think it should rather be sent out a feature request to the shells/libs (fish, bash, libreadline, libedit,, maybe zsh for first-class support) to make use of the existing mouse reporting VT sequences to get that. :-)

@christianparpart commented on GitHub (Sep 14, 2021): After reading through almost all of this, because i initially also liked that idea and considered implementing it on my end too, i now think it is absolutely wrong to implement that on the terminal emulator end. That is what the mouse reporting protocols are there for and it is the applications duty to make use of them instead of having the terminal emulator trying to brute force through them. I think it should rather be sent out a feature request to the shells/libs (fish, bash, libreadline, libedit,, maybe zsh for first-class support) to make use of the existing mouse reporting VT sequences to get that. :-)

claunia commented

@malxau commented on GitHub (Sep 14, 2021):

I think it should rather be sent out a feature request to the shells/libs (fish, bash, libreadline, libedit,, maybe zsh for first-class support) to make use of the existing mouse reporting VT sequences to get that. :-)

I may be missing something, but can you elaborate a bit more on how this would work?

AFAIK, the issue is that once an application requests mouse sequences, the terminal stops processing mouse sequences. That includes things like selection and scrolling. In the past (with conhost) I went down the "boil the ocean" route of trying to re-implement these features, which isn't ideal and leaves a real tension between two components trying to do the same thing and doing them slightly differently. With Terminal that isn't possible, because it doesn't expose the viewport (so no scrolling, see #10191 ), and there's no ability to read back buffer contents outside of the viewport, so selection doesn't work well either.

I think making this work would require fine grained mouse control specification, where an application can say things like "hey terminal, please tell me about mouse clicks, but please continue to handle mouse drag or scroll the way you previously did."

@malxau commented on GitHub (Sep 14, 2021): > I think it should rather be sent out a feature request to the shells/libs (fish, bash, libreadline, libedit,, maybe zsh for first-class support) to make use of the existing mouse reporting VT sequences to get that. :-) I may be missing something, but can you elaborate a bit more on how this would work? AFAIK, the issue is that once an application requests mouse sequences, the terminal stops processing mouse sequences. That includes things like selection and scrolling. In the past (with conhost) I went down the "boil the ocean" route of trying to re-implement these features, which isn't ideal and leaves a real tension between two components trying to do the same thing and doing them slightly differently. With Terminal that isn't possible, because it doesn't expose the viewport (so no scrolling, see #10191 ), and there's no ability to read back buffer contents outside of the viewport, so selection doesn't work well either. I think making this work would require fine grained mouse control specification, where an application can say things like "hey terminal, please tell me about mouse clicks, but please continue to handle mouse drag or scroll the way you previously did."

claunia commented

2026-01-31 02:57:29 +00:00

@christianparpart commented on GitHub (Sep 14, 2021):

Ah yes! You're perfectly right. I forgot about users may still want to be able to select some text in the main page area or scrollback buffer as well as having the ability to still scroll via mouse wheel events of course. That sounds conflicting, right - but so does the other way as already mentioned for example how to deal with cursor presses in relation to apps like vim/emacs etc.

So both ideas are conflicting on their own end - and - in the end both are heavily underspecced. Just like mouse selection and viewport scrolling is not part of the VT standard (mouse event interception though is!).

Although, most terminal emulators do support suppressing any activated mouse protocol by also pressing an additional modifier key (such as Shift) so users can press buttons regardless of the VT mouse protocol states.

If the modifier-solution is not enough, I think the only thing I can do to say how I would start approaching towards that goal, that is, by starting to communicate with other TE devs (from other TEs) and see if we can find a common ground that everybody agrees to and can be implemented.

That being said, I still think forcing the TE frontend to generate cursor move VT input sequences is wrong, because we already expose mouse protocol to the app side, so it should stay at the app side.

How to solve the task to be able to let the user use the mouse for grid cell selections / viewport changes without modifier and regardless of the mouse protocol being activated?

IIRC we have the following mouse modes:

X10 (9)
VT200 (100)
VT200 highlight (1001)
Button Event (1002)
Any Event (1003)

All these modes currently de-facto cause any mouse selection (without supress-modifier) to be directly passed to the app and will not be handled on the TE side.

What we want is a mode that causes the latter behavior to not happen, that is, whatever mouse protocol the app wants to use, and by default (!) then suppresses TE handling. I now propose a new DEC mode (whatever free number is available) that tells the TE to not suppress mouse handling on the TE-side when mouse tracking is enabled.

The presence of such a feature can be easily detected using DECRQM, enabled/disabled via SM/RM and should be handled in at least RIS as well.

Now an app such as bash/zsh/fish/... can enable mouse tracking AND enable that imaginary DEC mode I mentioned above to avoid the TE to suppress evaluating the mouse events (i.e. both ends are receiving/handling the events), whereas the app side (e.g. the shell) can use that to see if the mouse press event for example has actually happened inside the command prompt region, and if so, can move the cursor to that coordinate.

One side note would probably be, that mouse events are only to be received for the main page area (i.e. not the scrollback area).

p.s.: That imaginary mode should not necessarily mention that - if enabled - it will suppress mouse handling on the terminal side (should it?) but rather say that this is a only "passively" listening to these events, because it's not actively handling every mouse events (like in vim) but rather only when inside the shell's active prompt line. The TE then can use this information to indeed not disable own mouse handling. -- That's just how I would propose the wording for such a DEC mode.

p.p.s.: Sorry for the wall of text, and sorry, it's not meant to sound educational, I just didn't know how sparse or detailed I should reply to your question. :-)

@christianparpart commented on GitHub (Sep 14, 2021): Ah yes! You're perfectly right. I forgot about users may still want to be able to select some text in the main page area or scrollback buffer as well as having the ability to still scroll via mouse wheel events of course. That sounds conflicting, right - but so does the other way as already mentioned for example how to deal with cursor presses in relation to apps like vim/emacs etc. So both ideas are conflicting on their own end - and - in the end both are heavily underspecced. Just like mouse selection and viewport scrolling is not part of the VT standard (mouse event interception though is!). Although, most terminal emulators do support suppressing any activated mouse protocol by also pressing an additional modifier key (such as <kbd>Shift</kbd>) so users can press buttons regardless of the VT mouse protocol states. If the modifier-solution is not enough, I think the only thing I can do to say how **I** would start approaching towards that goal, that is, by starting to communicate with other TE devs (from other TEs) and see if we can find a common ground that everybody agrees to and can be implemented. That being said, I still think forcing the TE frontend to generate cursor move VT input sequences is wrong, because we already expose mouse protocol to the app side, so it should stay at the app side. How to solve the task to be able to let the user use the mouse for grid cell selections / viewport changes without modifier and regardless of the mouse protocol being activated? IIRC we have the following mouse modes: * X10 (9) * VT200 (100) * VT200 highlight (1001) * Button Event (1002) * Any Event (1003) All these modes currently de-facto cause any mouse selection (without supress-modifier) to be directly passed to the app and will not be handled on the TE side. What we want is a mode that causes the latter behavior to not happen, that is, whatever mouse protocol the app wants to use, and by default (!) then suppresses TE handling. I now propose a new DEC mode (whatever free number is available) that tells the TE to not suppress mouse handling on the TE-side when mouse tracking is enabled. The presence of such a feature can be easily detected using `DECRQM`, enabled/disabled via `SM`/`RM` and should be handled in at least `RIS` as well. Now an app such as bash/zsh/fish/... can enable mouse tracking AND enable that imaginary DEC mode I mentioned above to avoid the TE to suppress evaluating the mouse events (i.e. both ends are receiving/handling the events), whereas the app side (e.g. the shell) can use that to see if the mouse press event for example has actually happened inside the command prompt region, and if so, can move the cursor to that coordinate. One side note would probably be, that mouse events are only to be received for the main page area (i.e. not the scrollback area). p.s.: That imaginary mode should not necessarily mention that - if enabled - it will suppress mouse handling on the terminal side (should it?) but rather say that this is a only "passively" listening to these events, because it's not actively handling every mouse events (like in vim) but rather only when inside the shell's active prompt line. The TE then can use this information to indeed not disable own mouse handling. -- That's just how I would propose the wording for such a DEC mode. p.p.s.: Sorry for the wall of text, and sorry, it's not meant to sound educational, I just didn't know how sparse or detailed I should reply to your question. :-)

claunia commented

2026-01-31 02:57:29 +00:00

@christianparpart commented on GitHub (Sep 14, 2021):

[the terminal] doesn't expose the viewport

To that I wanted to add that the terminal did not seem to have any kind of scrollback but only pages (which work differently!), so the concept of scrollback and viewport is a new one. The app also can only modify the contents of the (main) page area(s). Adding VT sequences to cause the viewport to be changed would require a little more effort (e.g. the app would also need to know about the number of lines in the scrollback, ideally). I am not sure that would be actually anyhow helpful IMHO. :)

@christianparpart commented on GitHub (Sep 14, 2021): > [the terminal] doesn't expose the viewport To that I wanted to add that the terminal did not seem to have any kind of scrollback but only pages (which work differently!), so the concept of scrollback and viewport is a new one. The app also can only modify the contents of the (main) page area(s). Adding VT sequences to cause the viewport to be changed would require a little more effort (e.g. the app would also need to know about the number of lines in the scrollback, ideally). I am not sure that would be actually anyhow helpful IMHO. :)

claunia commented

@zadjii-msft commented on GitHub (Sep 14, 2021):

I now propose a new DEC mode (whatever free number is available) that tells the TE to not suppress mouse handling on the TE-side when mouse tracking is enabled.

The presence of such a feature can be easily detected using DECRQM, enabled/disabled via SM/RM and should be handled in at least RIS as well.

Now an app such as bash/zsh/fish/... can enable mouse tracking AND enable that imaginary DEC mode I mentioned above to avoid the TE to suppress evaluating the mouse events (i.e. both ends are receiving/handling the events), whereas the app side (e.g. the shell) can use that to see if the mouse press event for example has actually happened inside the command prompt region, and if so, can move the cursor to that coordinate.

I really like this idea. I probably don't have the cycles to really think through if there would be any issues with this design, but it seems like a good idea to me. It could work in tmux, it'll work over ssh, it'll work regardless of font size, those are usually the things that come to mind. Usually I'd hit up @j4james and @egmontkob for consensus on these types of things (RIP terminal-wg) based on their breadth of experience

@zadjii-msft commented on GitHub (Sep 14, 2021): > I now propose a new DEC mode (whatever free number is available) that tells the TE to not suppress mouse handling on the TE-side when mouse tracking is enabled. > > The presence of such a feature can be easily detected using `DECRQM`, enabled/disabled via `SM`/`RM` and should be handled in at least `RIS` as well. > > Now an app such as bash/zsh/fish/... can enable mouse tracking AND enable that imaginary DEC mode I mentioned above to avoid the TE to suppress evaluating the mouse events (i.e. both ends are receiving/handling the events), whereas the app side (e.g. the shell) can use that to see if the mouse press event for example has actually happened inside the command prompt region, and if so, can move the cursor to that coordinate. I really like this idea. I probably don't have the cycles to really think through if there would be any issues with this design, but it seems like a good idea to me. It could work in tmux, it'll work over ssh, it'll work regardless of font size, those are usually the things that come to mind. Usually I'd hit up @j4james and @egmontkob for consensus on these types of things (RIP terminal-wg) based on their breadth of experience

claunia commented

@j4james commented on GitHub (Sep 14, 2021):

I'm not a fan of inventing new functionality like this, because it's so easy to get wrong. You often end up with something that only works for your one specific use case, which leads to someone else implement something slightly different that meets their needs, and before you know it you've got a half a dozen new modes doing almost exactly the same thing (just look at all the existing mouse modes to see how that pans out).

So the first thing I'd want to know was if you could achieve what you want using existing functionality. I haven't done much work with the DEC locator sequences, but I was wondering whether perhaps the filter rectangle could be of use for this sort of thing. The idea being that you would set a filter to track the areas of the screen in which you want to take control of the mouse, and when the mouse enter your area you enable mouse capture, and when it leaves your area you disable the mouse capture.

I don't know if the filters can actually be used that way, but that's the first thing I'd want to try.

@j4james commented on GitHub (Sep 14, 2021): I'm not a fan of inventing new functionality like this, because it's so easy to get wrong. You often end up with something that only works for your one specific use case, which leads to someone else implement something slightly different that meets their needs, and before you know it you've got a half a dozen new modes doing almost exactly the same thing (just look at all the existing mouse modes to see how that pans out). So the first thing I'd want to know was if you could achieve what you want using existing functionality. I haven't done much work with the DEC locator sequences, but I was wondering whether perhaps the filter rectangle could be of use for this sort of thing. The idea being that you would set a filter to track the areas of the screen in which you want to take control of the mouse, and when the mouse enter your area you enable mouse capture, and when it leaves your area you disable the mouse capture. I don't know if the filters can actually be used that way, but that's the first thing I'd want to try.

claunia commented

@softworkz commented on GitHub (Oct 14, 2021):

This is the one feature that I'm missing the most in WT.

A possibly useful information: ConEmu can do this as well.
And it has a BSD3 license..

@softworkz commented on GitHub (Oct 14, 2021): This is the one feature that I'm missing the most in WT. A possibly useful information: ConEmu can do this as well. And it has a BSD3 license..

claunia commented

@DHowett commented on GitHub (Oct 14, 2021):

Our disagreement is not over finding an implementation, it's about whether it is worth implementing given the risks, downsides and opportunity for confusion. 😄

@DHowett commented on GitHub (Oct 14, 2021): Our disagreement is not over finding an implementation, it's about whether it is worth implementing given the risks, downsides and opportunity for confusion. :smile:

claunia commented

@softworkz commented on GitHub (Oct 14, 2021):

Our disagreement is not over finding an implementation, it's about whether it is worth implementing given the risks, downsides and opportunity for confusion. 😄

You mean "confusion" at the user side?
How could it be confusing that the cursor is getting repositioned on click, like everywhere else on Windows?

PS: I don't understand the hiding of the comments above.

@softworkz commented on GitHub (Oct 14, 2021): > Our disagreement is not over finding an implementation, it's about whether it is worth implementing given the risks, downsides and opportunity for confusion. 😄 You mean "confusion" at the user side? How could it be confusing that the cursor is getting repositioned on click, like everywhere else on Windows? PS: I don't understand the hiding of the comments above.

claunia commented

@zadjii-msft commented on GitHub (Oct 14, 2021):

How could it be confusing that the cursor is getting repositioned on click, like everywhere else on Windows?

The whole thread is full of examples of weird edge cases where the user might be confused by what happens. It's not necessarily as simple as "just move the cursor there". Cool and magical when it works, “something is a bit off” when it doesn’t.

PS: I don't understand the hiding of the comments above.

In general, we tend to minimize comments like that because it basically amounts to a "+1" in the midst of a thread that's otherwise filled with productive conversation on the details of how we might actually implement this.

@zadjii-msft commented on GitHub (Oct 14, 2021): > How could it be confusing that the cursor is getting repositioned on click, like everywhere else on Windows? The whole thread is full of examples of weird edge cases where the user might be confused by what happens. It's not necessarily as simple as "just move the cursor there". _Cool and magical when it works, “something is a bit off” when it doesn’t._ > PS: I don't understand the hiding of the comments above. In general, we tend to minimize comments like that because it basically amounts to a "+1" in the midst of a thread that's otherwise filled with productive conversation on the details of how we might actually implement this.

claunia commented

@softworkz commented on GitHub (Oct 14, 2021):

There was a conversation about mintty at the top and it was mentioned that it can't be looked at due to it's licensing.

Then @j4james was talking about risks and how easy it would be to get it wrong, which looked like this subject might have gotten stalled.

That's why I had posted the reference to ConEMU. No matter how good you're considering and relying on your own skills: taking a look at an implementation that is confirmed to be working well, does for once provide proof that it can be done without/low risk and might also give some inspiration or ideas.

I didn't want to turn this into a mee-too feature-voting conversation, I guess I shouldn't have written the first sentence.

@softworkz commented on GitHub (Oct 14, 2021): There was a conversation about mintty at the top and it was mentioned that it can't be looked at due to it's licensing. Then @j4james was talking about risks and how easy it would be to get it wrong, which looked like this subject might have gotten stalled. That's why I had posted the reference to ConEMU. No matter how good you're considering and relying on your own skills: taking a look at an implementation that is confirmed to be working well, does for once provide proof that it can be done without/low risk and might also give some inspiration or ideas. I didn't want to turn this into a mee-too feature-voting conversation, I guess I shouldn't have written the first sentence.

claunia commented

@j4james commented on GitHub (Oct 21, 2021):

I just realised that one approach to implementing this would be using the Final Term prompt markup sequences supported by iTerm2 and others (for the details, search for FTCS in the iTerm2 documentation).

If a shell has been configured to output those sequences, a terminal should be able to determine exactly which area of the screen is within the active command line, so if we see a mouse click in that range, it's probably safe to send the appropriate key sequences to move the cursor (possibly still as an optional feature).

It's also worth noting that the Final Term sequences have been discussed before as a solution to issues #6232 and #9881, so there are multiple benefits we can get from this approach.

@j4james commented on GitHub (Oct 21, 2021): I just realised that one approach to implementing this would be using the _Final Term_ prompt markup sequences supported by iTerm2 and others (for the details, search for `FTCS` in the [iTerm2 documentation](https://iterm2.com/documentation-escape-codes.html)). If a shell has been configured to output those sequences, a terminal should be able to determine exactly which area of the screen is within the active command line, so if we see a mouse click in that range, it's probably safe to send the appropriate key sequences to move the cursor (possibly still as an optional feature). It's also worth noting that the _Final Term_ sequences have been discussed before as a solution to issues #6232 and #9881, so there are multiple benefits we can get from this approach.

claunia commented

@KalleOlaviNiemitalo commented on GitHub (Jan 11, 2022):

If the user has pressed Ctrl+V Ctrl+G in a shell to type the BEL control character, and the shell displays that as ^G but treats it as a single character for line editing, how can the terminal know that it needs to send just one arrow-key event to get past that character, rather than two?

@KalleOlaviNiemitalo commented on GitHub (Jan 11, 2022): If the user has pressed Ctrl+V Ctrl+G in a shell to type the BEL control character, and the shell displays that as `^G` but treats it as a single character for line editing, how can the terminal know that it needs to send just one arrow-key event to get past that character, rather than two?

claunia commented

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

and the shell displays that as ^G but treats it as a single character for line editing

That's a great example of an edge case where I would expect this to not work correctly.

@zadjii-msft commented on GitHub (Jan 11, 2022): > and the shell displays that as `^G` but treats it as a single character for line editing That's a great example of an edge case where I would expect this to not work correctly.

claunia commented

@j4james commented on GitHub (Jan 11, 2022):

Just checked how Mintty handles it, and it looks like it just gets everything off by one (or more if you've got multiple instances of those characters). Technically I think we could potentially correct for that sort of thing, because we know exactly where the cursor is, so we can adjust how many keypresses we send based on where the cursor ends up.

@j4james commented on GitHub (Jan 11, 2022): Just checked how Mintty handles it, and it looks like it just gets everything off by one (or more if you've got multiple instances of those characters). Technically I think we could potentially correct for that sort of thing, because we know exactly where the cursor is, so we can adjust how many keypresses we send based on where the cursor ends up.

claunia commented

Impl: https://github.com/xtermjs/xterm.js/blob/master/src/browser/input/MoveToCell.ts

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

Some tips, courtesy of @Tyriar

If you ignore the editor case and only focus on only the normal buffer (if you can distinguish this on Windows?), you can cut out a lot of the unreliability
Some shells automatically indent the 2nd+ line to align it with the prompt which throws the feature out of whack
If you cover the alt buffer, it seemed more reliable to send left to the start of the line, then up/down, then right

@zadjii-msft commented on GitHub (Jan 11, 2022): Some tips, courtesy of @Tyriar * If you ignore the editor case and only focus on only the normal buffer (if you can distinguish this on Windows?), you can cut out a lot of the unreliability * Some shells automatically indent the 2nd+ line to align it with the prompt which throws the feature out of whack * If you cover the alt buffer, it seemed more reliable to send left to the start of the line, then up/down, then right Impl: https://github.com/xtermjs/xterm.js/blob/master/src/browser/input/MoveToCell.ts

claunia commented

2026-01-31 02:57:33 +00:00

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

VSCode for me is able to move the cursor with alt+click on any terminal I've tried, though admittedly there is weird behaviour that sometimes clears the line completely and leaves a [C or [D

@con-dog commented on GitHub (Jan 13, 2022): VSCode for me is able to move the cursor with alt+click on any terminal I've tried, though admittedly there is weird behaviour that sometimes clears the line completely and leaves a [C or [D

claunia commented

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

VSCode for me is able to move the cursor with alt+click on any terminal I've tried,

Agree. I see no reason why we cannot grab that piece of code and port this functionality from VSCode, provided it were open-source

@Suncatcher commented on GitHub (Jun 22, 2022): > VSCode for me is able to move the cursor with alt+click on any terminal I've tried, Agree. I see no reason why we cannot grab that piece of code and port this functionality from VSCode, provided it were open-source

claunia commented

2026-01-31 02:57:33 +00:00

@zadjii-msft commented on GitHub (Jun 22, 2022):

I literally linked the VsCode implementation just two comments above: https://github.com/microsoft/terminal/issues/8573#issuecomment-1010137633. I worry that there'll be plenty of edge cases where this doesn't work as expected, but maybe that's not a reason to reject it entirely. I'd certainly be interested if someone could take that vscode example and translate it to the Windows Terminal (under an experimental setting for now). TermControl and ControlCore are probably the parts of the code that would likely need to be responsible for handling this. If anyone's interested, @ me in this thread and I can try and give more tips of where I'd start.

@zadjii-msft commented on GitHub (Jun 22, 2022): I literally linked the VsCode implementation just two comments above: https://github.com/microsoft/terminal/issues/8573#issuecomment-1010137633. I worry that there'll be plenty of edge cases where this doesn't work as expected, but maybe that's not a reason to reject it entirely. I'd certainly be interested if someone could take that vscode example and translate it to the Windows Terminal (under an experimental setting for now). `TermControl` and `ControlCore` are probably the parts of the code that would likely need to be responsible for handling this. If anyone's interested, @ me in this thread and I can try and give more tips of where I'd start.

claunia commented

2026-01-31 02:57:33 +00:00

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

To be fair, I think that implementing such a thing in a terminal emulator in the suggested way is not how it should be done. Instead, an application (this includes bash and ZSH) should utilize the already existing protocols, to receive mouse click events. Having that implemented in a shell instantly enables this functionality in all terminals utilizing mouse support. Implementing such a feature the other way around would be wrong, in my opinion (if that matters).

Programs like vim and emacs are doing that for decades, a shell is no different (from the TEs point of view).

@christianparpart commented on GitHub (Jun 22, 2022): To be fair, I think that implementing such a thing in a terminal emulator in the suggested way is not how it should be done. Instead, an application (this includes bash and ZSH) should utilize the already existing protocols, to receive mouse click events. Having that implemented in a shell instantly enables this functionality in **all** terminals utilizing mouse support. Implementing such a feature the other way around would be wrong, in my opinion (if that matters). Programs like vim and emacs are doing that for decades, a shell is no different (from the TEs point of view).

claunia commented

@zadjii-msft commented on GitHub (Jun 22, 2022):

FWIW, from a purely technical standpoint, I totally agree. I'd wish there was a better way for a shell to request sensible mouse input, and I love your proposal.

I also don't want the perfect to be the enemy of good - if someone wants to contribute this as a workaround while "the maintainers formerly known as Terminal WG" discuss an ideal solution, I'm fine taking that as an "experimental" feature. Never describing it as anything more than "something that will have a lot of edge cases".

I've got a fixation myself to do the rest of the final term sequences soon (#11000), but even those aren't perfect. cmd.exe doesn't have a way for us to emit something equivalent to preexec, nor can it get the error level at the prompt, so it'd be limited to 133;A and 133;B. Maybe if we're thinking of tying this with the final term feature, we could at least limit mouse clicks to the region [wherever the last 133;B was, the end of the viewport]. I suppose even in bash, that is all there would be for the current active prompt. Okay I talked myself into that.

@zadjii-msft commented on GitHub (Jun 22, 2022): FWIW, from a purely technical standpoint, I totally agree. I'd wish there was a better way for a shell to request sensible mouse input, and I love your proposal. I also don't want the perfect to be the enemy of good - if someone wants to contribute this as a workaround while "the maintainers formerly known as Terminal WG" discuss an ideal solution, I'm fine taking that as an "experimental" feature. Never describing it as anything more than "something that will have a lot of edge cases". <hr> I've got a fixation myself to do the rest of the final term sequences soon (#11000), but even those aren't perfect. `cmd.exe` doesn't have a way for us to emit something equivalent to [`preexec`](https://superuser.com/questions/175799/does-bash-have-a-hook-that-is-run-before-executing-a-command), nor can it get the error level at the prompt, so it'd be limited to `133;A` and `133;B`. Maybe if we're thinking of tying this with the final term feature, we could at least limit mouse clicks to the region [wherever the last `133;B` was, the end of the viewport]. I suppose even in bash, that is all there would be for the current active prompt. Okay I talked myself into that.

claunia commented

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

This is probably the only ever GH conversation where I'm writing as a pure user rather than a developer and I also learned above that user comments are undesired, but I'd still like to add that - even though I very well understand the motivation for perfection - it would be an improvement of incredibly high value for average users of the terminal who are using it for nothing more than issuing cmd or PS commands, which surely makes the largest share of use cases. Many of the advanced capabilities of the terminal are targeting a relatively small audience and use cases, especially when including WT as replacement to the legacy command prompt.

Even as advanced user and developer (7 years MS MVP for Windows API and C++), very few of the many planned or discussed terminal-level features are of much interest. On the other side, it happens every second or third day that I wish I could position the cursor in the terminal somewhere inside a lengthy command instead of spending time moving the cursor with left/right all the way through to the right position.

It doesn't need to work in all possible cases. When it would just work in the very most simple case, which is going back to a previous command (w up/down) and then positioning the cursor somewhere inside this command to make modifications - that alone would be a huge value for everyday use - and for a wide range of users.

@softworkz commented on GitHub (Jun 22, 2022): This is probably the only ever GH conversation where I'm writing as a pure user rather than a developer and I also learned above that user comments are undesired, but I'd still like to add that - even though I very well understand the motivation for perfection - it would be an improvement of incredibly high value for average users of the terminal who are using it for nothing more than issuing cmd or PS commands, which surely makes the largest share of use cases. Many of the advanced capabilities of the terminal are targeting a relatively small audience and use cases, especially when including WT as replacement to the legacy command prompt. Even as advanced user and developer (7 years MS MVP for Windows API and C++), very few of the many planned or discussed terminal-level features are of much interest. On the other side, it happens every second or third day that I wish I could position the cursor in the terminal somewhere inside a lengthy command instead of spending time moving the cursor with left/right all the way through to the right position. It doesn't need to work in all possible cases. When it would just work in the very most simple case, which is going back to a previous command (w up/down) and then positioning the cursor somewhere inside this command to make modifications - that alone would be a huge value for everyday use - and for a wide range of users.

claunia commented

@zadjii-msft commented on GitHub (Jun 22, 2022):

FWIW, we take comments like the above into account, but hide them because of the visual noise they add to the thread. IMO, in the middle of the technical discussion of how to implement this, it's best to collapse comments reiterating a desire for the requested feature. Sorry, we certainly meant no offense!

@zadjii-msft commented on GitHub (Jun 22, 2022): FWIW, we take comments like the above into account, but hide them because of the visual noise they add to the thread. IMO, in the middle of the technical discussion of _how_ to implement this, it's best to collapse comments reiterating a desire for the requested feature. Sorry, we certainly meant no offense!

claunia commented

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

Sometimes, dev discussions need a little tear-down "back to earth and reality". That was my impression while following the discussion and my motivation for posting the above. I removed my last sentence and you might want to hide this and your previous comment to avoid "pollution" :-)

@softworkz commented on GitHub (Jun 22, 2022): Sometimes, dev discussions need a little tear-down "back to earth and reality". That was my impression while following the discussion and my motivation for posting the above. I removed my last sentence and you might want to hide this and your previous comment to avoid "pollution" :-)

claunia commented

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

Sometimes, dev discussions need a little tear-down "back to earth and reality".

Naw, you're totally right. Thanks for bearing with us!

@DHowett commented on GitHub (Jun 22, 2022): > Sometimes, dev discussions need a little tear-down "back to earth and reality". Naw, you're totally right. Thanks for bearing with us!

claunia commented

@zadjii-msft commented on GitHub (Feb 24, 2023):

x-linking a thread that looks relevant: "Passive Mouse Tracking & Text Selection Tracking VT extensions.", terminal-wg/specifications#31

@zadjii-msft commented on GitHub (Feb 24, 2023): x-linking a thread that looks relevant: "Passive Mouse Tracking & Text Selection Tracking VT extensions.", [terminal-wg/specifications#31](https://gitlab.freedesktop.org/terminal-wg/specifications/-/issues/31)

claunia commented

@christianparpart commented on GitHub (Feb 24, 2023):

@zadjii-msft this is exactly what I was aiming for, while the spec I wrote it as general purpose as it can get, I also wrote a small sample CLI app to demo the event reporting. If you find design flaws, please /cc me in any way. :)

@christianparpart commented on GitHub (Feb 24, 2023): @zadjii-msft this is *exactly* what I was aiming for, while the spec I wrote it as general purpose as it can get, I also wrote a small sample CLI app to demo the event reporting. If you find design flaws, please /cc me in any way. :)

claunia commented

@zadjii-msft commented on GitHub (Jul 12, 2023):

huh, just noticed this block on invisible-island

CSI ? Pm h
      DEC Private Mode Set (DECSET).
        Ps = 2 0 0 1  ⇒  Enable readline mouse button-1, xterm.
        Ps = 2 0 0 2  ⇒  Enable readline mouse button-2, xterm.
        Ps = 2 0 0 3  ⇒  Enable readline mouse button-3, xterm.
        Ps = 2 0 0 4  ⇒  Set bracketed paste mode, xterm.
        Ps = 2 0 0 5  ⇒  Enable readline character-quoting, xterm.
        Ps = 2 0 0 6  ⇒  Enable readline newline pasting, xterm.

and also on https://github.com/mintty/mintty/wiki/CtrlSeqs#readline-mouse-modes

These three mode settings, switched by DECSET/DECRST sequences (xterm 379) enable mouse-controlled editing on the command line (as detected by the cursor position) by sending virtual cursor or erase keystrokes.

sequence mode

^[[?2001h left button places cursor on command line

^[[?2002h middle button pastes at current mouse position

^[[?2003h double right-click deletes selection until mouse position

did this get added to xterm while no one was looking?

@zadjii-msft commented on GitHub (Jul 12, 2023): huh, just noticed this block on invisible-island CSI ? Pm h DEC Private Mode Set (DECSET). Ps = 2 0 0 1 ⇒ Enable readline mouse button-1, xterm. Ps = 2 0 0 2 ⇒ Enable readline mouse button-2, xterm. Ps = 2 0 0 3 ⇒ Enable readline mouse button-3, xterm. Ps = 2 0 0 4 ⇒ Set bracketed paste mode, xterm. Ps = 2 0 0 5 ⇒ Enable readline character-quoting, xterm. Ps = 2 0 0 6 ⇒ Enable readline newline pasting, xterm. and also on https://github.com/mintty/mintty/wiki/CtrlSeqs#readline-mouse-modes > These three mode settings, switched by DECSET/DECRST sequences (xterm 379) enable mouse-controlled editing on the command line (as detected by the cursor position) by sending virtual cursor or erase keystrokes. > > sequence | mode > -- | -- > ^[[?2001h | left button places cursor on command line > ^[[?2002h | middle button pastes at current mouse position > ^[[?2003h | double right-click deletes selection until mouse position > did this get added to xterm while no one was looking?

claunia commented

@j4james commented on GitHub (Jul 12, 2023):

did this get added to xterm while no one was looking?

I think that stuff has existed for years - it's only just been documented recently. And I think it was (possibly still is) behind a build flag, so maybe wasn't enabled by default.

@j4james commented on GitHub (Jul 12, 2023): > did this get added to xterm while no one was looking? I think that stuff has existed for years - it's only just been documented recently. And I think it was (possibly still is) behind a build flag, so maybe wasn't enabled by default.

claunia commented

@GaryAtlan82 commented on GitHub (Jul 20, 2023):

This has been a long issues of mine, my sentiments are the same as @softworkz.
I am still fairly new to this opposing Terminal vs GUI world. I really dont like seeing them as two diametrically oppossed approaches to using a PC and have been trying to reduce this friction as much as I can.

This feature is really at the core of this friction. A universal means of setting cursor position and even selecting words, regardless of the underlying client, would be such a watershed momment.

You guys have done some amazing stuff with windows terminal, I know you will achieve this too.

@GaryAtlan82 commented on GitHub (Jul 20, 2023): This has been a long issues of mine, my sentiments are the same as @softworkz. I am still fairly new to this opposing Terminal vs GUI world. I really dont like seeing them as two diametrically oppossed approaches to using a PC and have been trying to reduce this friction as much as I can. This feature is really at the core of this friction. A universal means of setting cursor position and even selecting words, regardless of the underlying client, would be such a watershed momment. You guys have done some amazing stuff with windows terminal, I know you will achieve this too.

claunia commented

@zadjii-msft commented on GitHub (Jul 20, 2023):

The dumbest possible solution: Only emit keys WHEN:

the setting is on
The click is somewhere after the "active command" mark.¹
You clicked on the line WITH THE CURSOR.

and even then just blindly emit one arrow key per cell. Literally as dumb as possible.

Does it work for wrapped lines? Nope.
Does it work for vim? Nope.
Does it work for emoji/wide glyphs? I mean, emoji input is fucked anyways, right?
Does it do selections? Nope.
Lines with continuation prompts? As long as you don't click on the > , sure?

In VT mouse mode? Don't do it. The app wanted mouse.
Pressed shift? Don't do it. Make a selection.

I hate that I feel okay with this. Like, yes, yes, the shell should handle this, there's so many ways for it to not work, but like... idk. Now that I see it in action... it seems more okay. We could probably round out some of the edge cases to make it a little more accurate.

Maybe just cause I'm high on shell integration so anything that looks like an application for it, I'm like YEA LET'S DO IT. I need an unbiased opinion.

This means it requires shell integration to be enabled. ↩︎

@zadjii-msft commented on GitHub (Jul 20, 2023): The dumbest possible solution: Only emit keys WHEN: * the setting is on * The click is somewhere _after_ the "active command" mark.[^1] * You clicked on the line WITH THE CURSOR. and even then just blindly emit one arrow key per cell. Literally as dumb as possible. ![8573-in-the-dumbest-way](https://github.com/microsoft/terminal/assets/18356694/d6c744f8-ed20-4d8e-908b-c39794718a62) Does it work for wrapped lines? Nope. Does it work for `vim`? Nope. Does it work for emoji/wide glyphs? I mean, emoji input is fucked anyways, right? Does it do selections? Nope. Lines with continuation prompts? As long as you don't click on the `> `, sure? In VT mouse mode? Don't do it. The app wanted mouse. Pressed `shift`? Don't do it. Make a selection. --- I hate that I feel okay with this. Like, yes, yes, the shell _should_ handle this, there's so many ways for it to not work, but like... idk. Now that I see it in action... it seems more okay. We could probably round out some of the edge cases to make it a little more accurate. Maybe just cause I'm high on shell integration so anything that looks like an application for it, I'm like _YEA LET'S DO IT_. I need an unbiased opinion. [^1]: This means it requires shell integration to be enabled.

claunia commented

@j4james commented on GitHub (Jul 20, 2023):

The dumbest possible solution: Only emit keys WHEN:
* the setting is on

* The click is somewhere _after_ the "active command" mark.[1](#user-content-fn-1-bf5dd1751f3b9b514bf4e8568fc9c371)

* You clicked on the line WITH THE CURSOR.
and even then just blindly emit one arrow key per cell. Literally as dumb as possible.

I think this is perfectly reasonable. Tying it to the active command makes it feel a lot safer than just triggering it on arbitrary clicks. I'd even go so far as to say that we could probably accept clicks on any line from the active command mark and below (assuming the cursor is also past the active command mark).

@j4james commented on GitHub (Jul 20, 2023): > The dumbest possible solution: Only emit keys WHEN: > > * the setting is on > > * The click is somewhere _after_ the "active command" mark.[1](#user-content-fn-1-bf5dd1751f3b9b514bf4e8568fc9c371) > > * You clicked on the line WITH THE CURSOR. > > > and even then just blindly emit one arrow key per cell. Literally as dumb as possible. I think this is perfectly reasonable. Tying it to the active command makes it feel a lot safer than just triggering it on arbitrary clicks. I'd even go so far as to say that we could probably accept clicks on any line from the active command mark and below (assuming the cursor is also past the active command mark).

claunia commented

@softworkz commented on GitHub (Jul 20, 2023):

If it doesn't work for wrapped lines, it's not much useful, because it's those wrapped lines where it 's most tedious to navigate to a specific position via cursor keys.

@softworkz commented on GitHub (Jul 20, 2023): If it doesn't work for wrapped lines, it's not much useful, because it's those wrapped lines where it 's most tedious to navigate to a specific position via cursor keys.

claunia commented

@zadjii-msft commented on GitHub (Aug 23, 2023):

I'm tempted to call this closed by #15758 - I'm not sure what more we'd do here.

I'm also not sure I'd know when to call this not experimental. It's like, pretty definitively not going to work all the time, so I want that to be clear. But it does work most of the time?

@zadjii-msft commented on GitHub (Aug 23, 2023): I'm tempted to call this closed by #15758 - I'm not sure what more we'd do here. I'm also not sure I'd know when to call this _not_ experimental. It's like, pretty definitively not going to work all the time, so I want that to be clear. But it does work most of the time?

claunia commented

@christianparpart commented on GitHub (Aug 29, 2023):

@zadjii-msft while I am aware that this might be the most straight forward solution in terms of getting it quickly done, it comes with its caveats, as very well known.

Some months ago, I was drafting a potentially better solution and also gathered some feedback from @jerch, textshell and others directly or over there on IRC.
What would you think about a solution such as:

This should probably not change the decision on closing this ticket here, but I'd like to raise your interest in thinking more forward for a potential better solution.

NB: I've experimentally implemented the above proposals on my TE end along with a simple CLI example. But shells so far (the one I asked for) is still a little conservative on change, but that's nothing new to me. Looks like I'll also end up implementing a shell, eventually :)

@christianparpart commented on GitHub (Aug 29, 2023): @zadjii-msft while I am aware that this might be the most straight forward solution in terms of getting it quickly done, it comes with its caveats, as very well known. Some months ago, I was drafting a potentially better solution and also gathered some feedback from @jerch, textshell and others directly or over there on IRC. What would you think about a solution such as: - [Passive Mouse Tracking Extension](https://github.com/contour-terminal/vt-extensions/blob/master/passive-mouse-tracking.md) - [Text Selection Tracking Extension](https://github.com/contour-terminal/vt-extensions/blob/master/text-selection-tracking.md) This should probably not change the decision on closing this ticket here, but I'd like to raise your interest in thinking more forward for a potential better solution. NB: I've experimentally implemented the above proposals on my TE end along with a simple CLI example. But shells so far (the one I asked for) is still a little conservative on change, but that's nothing new to me. Looks like I'll also end up implementing a shell, eventually :)

claunia commented

@softworkz commented on GitHub (Apr 3, 2024):

I'm tempted to call this closed by #15758 - I'm not sure what more we'd do here.

I think there's a bunch of things left to do:

Add it to the schema
(it's currently neither in in https://aka.ms/terminal-profiles-schema nor in https://aka.ms/terminal-profiles-schema-preview)
Stop calling it experimental
Add it to the config UI
Make it a single-click activation
After half an hour, I still haven't figured out how to enable it. The docs are pointing to "How to enable shell integration marks", but this page is only talking about "marrks on scrollbar", "right-click menu" and "automarkPrompts".
Seriously: I want none of that. I also don't want to modify the prompts, nor even deal with this in any way. I just want to be able to "click to position the cursor" - that's all. How to do it without messing around with those things?
Move it from "advanced" to a "general" feature
It is currently hidden deeply amongst a hundred of features, most of which I had never thought of anybody would ever want or need, while this is the single most important one of all (IMHO)

Note: I got it working a while ago on a different machine with the preview, but it took me a long time to get there and I don't remember what I did. It's incredibly painful, having to deal with changing the prompts (even though I don't want to change them actually).
But what I can say from the time where I had it working: It's all fine they way it is and how it works. None of those cases you are frequently talking about - where it doesn't work - is of any interest or will ever be of any interest to me with regards to this feature.
IMO it's all good, except the way for enabling it.

@softworkz commented on GitHub (Apr 3, 2024): > I'm tempted to call this closed by #15758 - I'm not sure what more we'd do here. I think there's a bunch of things left to do: - Add it to the schema (it's currently neither in in https://aka.ms/terminal-profiles-schema nor in https://aka.ms/terminal-profiles-schema-preview) - Stop calling it experimental - Add it to the config UI - Make it a single-click activation After half an hour, I still haven't figured out how to enable it. The docs are pointing to "How to enable shell integration marks", but this page is only talking about "marrks on scrollbar", "right-click menu" and "automarkPrompts". Seriously: I want none of that. I also don't want to modify the prompts, nor even deal with this in any way. I just want to be able to "click to position the cursor" - that's all. How to do it without messing around with those things? - Move it from "advanced" to a "general" feature It is currently hidden deeply amongst a hundred of features, most of which I had never thought of anybody would ever want or need, while this is the single most important one of all (IMHO) Note: I got it working a while ago on a different machine with the preview, but it took me a long time to get there and I don't remember what I did. It's incredibly painful, having to deal with changing the prompts (even though I don't want to change them actually). But what I can say from the time where I had it working: It's all fine they way it is and how it works. None of those cases you are frequently talking about - where it doesn't work - is of any interest or will ever be of any interest to me with regards to this feature. IMO it's all good, except the way for enabling it.

claunia commented

@sarim commented on GitHub (Apr 3, 2024):

Stop calling it experimental

It is called experimental because it is experimental. Few weeks ago I tried to use it, but its unstable for daily usage. It frequently hanged the terminal by putting itself in infinite loop of sending left arrow keystroke, activate itself while trying to copy text by left click and dragging etc... I didn't had the time to debug so stopped using it for now. Will try to debug and report issue when I get the time.

Add it to the schema

Should be fixed when #16652 lands.

@sarim commented on GitHub (Apr 3, 2024): > * Stop calling it experimental It is called experimental because it is experimental. Few weeks ago I tried to use it, but its unstable for daily usage. It frequently hanged the terminal by putting itself in infinite loop of sending left arrow keystroke, activate itself while trying to copy text by left click and dragging etc... I didn't had the time to debug so stopped using it for now. Will try to debug and report issue when I get the time. > * Add it to the schema Should be fixed when #16652 lands.

claunia commented

@zadjii-msft commented on GitHub (Apr 3, 2024):

Add it to the schema

(as mentioned above: https://github.com/microsoft/terminal/issues/8573#issuecomment-2035197181)

Stop calling it experimental

Yea, I think I've lined out at length in this thread why I believe that this needs to remain an "experimental" feature. A permanent one, but one that's got enough edge cases that the average user will likely run into one and not understand why.

Add it to the config UI

Already done in #16809

Make it a single-click activation

I've got designs of my own to make "automatic shell integration" work, in the same vein as the way VsCode does. That however, is far beyond the scope of this thread. #13445 is probably the closest in spirit, though I'll probably fork off a dedicated thread when that gets closer to landing. I'd much rather keep threads more tightly coupled with atomic bits of work, and I'm not about to hold this one open, waiting on some piece of work that can be done independently.

@christianparpart Sorry I missed that comment! I don't even think I was on vacation or anything, so I have no idea how it slipped by. Passive mouse tracking looks great for shells that can support it. I think this is a good example of "yes, and" - passive mouse tracking is better for the shells that can support that. For crochety old men like me who like CMD, then I'll have to make do with this experimental mode

wait

can we have OpenConsole just opt in to passive tracking? Like, always send openconsole passive events, if we're not in VT mouse input mode? This is a half backed thought. But maybe there's a way for us to know that

the client app didn't actually ask for mouse input
and it's doing a cooked read
but OpenConsole can handle mouse input to move the cursor within the cooked read

I'd need think on that for a while. Feels like the dough is under-proved on that thought.

@zadjii-msft commented on GitHub (Apr 3, 2024): > Add it to the schema (as mentioned above: https://github.com/microsoft/terminal/issues/8573#issuecomment-2035197181) > Stop calling it experimental Yea, I think I've lined out at length in this thread why I believe that this needs to remain an "experimental" feature. A permanent one, but one that's got enough edge cases that the average user will likely run into one and not understand why. > Add it to the config UI Already done in #16809 > Make it a single-click activation I've got designs of my own to make "automatic shell integration" work, in the same vein as the way VsCode does. That however, is far beyond the scope of this thread. #13445 is probably the closest in spirit, though I'll probably fork off a dedicated thread when that gets closer to landing. I'd much rather keep threads more tightly coupled with atomic bits of work, and I'm not about to hold this one open, waiting on some piece of work that can be done independently. ---- @christianparpart Sorry I missed that comment! I don't even think I was on vacation or anything, so I have no idea how it slipped by. Passive mouse tracking looks great for shells that can support it. I think this is a good example of "yes, and" - passive mouse tracking is better for the shells that can support that. For crochety old men like me who like CMD, then I'll have to make do with this experimental mode wait _can we have OpenConsole just opt in to passive tracking_? Like, always send openconsole passive events, if we're not in VT mouse input mode? This is a half backed thought. But maybe there's a way for us to know that * the client app didn't actually ask for mouse input * and it's doing a cooked read * but OpenConsole can handle mouse input to move the cursor within the cooked read I'd need think on that for a while. Feels like the dough is under-proved on that thought.

claunia commented

@softworkz commented on GitHub (Apr 3, 2024):

Add it to the config UI

Already done in #16809

Awesome!

Make it a single-click activation

I've got designs of my own to make "automatic shell integration" work, in the same vein as the way VsCode does. That however, is far beyond the scope of this thread. #13445 is probably the closest in spirit, though I'll probably fork off a dedicated thread when that gets closer to landing. I'd much rather keep threads more tightly coupled with atomic bits of work, and I'm not about to hold this one open,..

Yea sure, I didn't mean to say this needs to be kept open, I was merely afraid that this might remain an unknown and forgotten feature, which is hardly accessible and lastly will make me hate all this each time I'm on a different machine ;-)

Would you kindly help me out with what exactly I need to do to enable this for cmd and PowerShell without changing anything else (it's all at defaults)?
And maybe add it to the docs page to which the text about the setting is linking to but which doesn't even mention it and neither discriminates which modification is needed for which feature exactly.

@softworkz commented on GitHub (Apr 3, 2024): > > Add it to the config UI > > Already done in #16809 Awesome! > > Make it a single-click activation > > I've got designs of my own to make "automatic shell integration" work, in the same vein as the way VsCode does. That however, is far beyond the scope of this thread. #13445 is probably the closest in spirit, though I'll probably fork off a dedicated thread when that gets closer to landing. I'd much rather keep threads more tightly coupled with atomic bits of work, and I'm not about to hold this one open,.. Yea sure, I didn't mean to say this needs to be kept open, I was merely afraid that this might remain an unknown and forgotten feature, which is hardly accessible and lastly will make me hate all this each time I'm on a different machine ;-) Would you kindly help me out with what exactly I need to do to enable this for cmd and PowerShell without changing anything else (it's all at defaults)? And maybe add it to the docs page to which the text about the setting is linking to but which doesn't even mention it and neither discriminates which modification is needed for which feature exactly.

claunia commented

@cow1337killer3 commented on GitHub (Apr 29, 2024):

Wow it's 2024 and we still can't move a terminal cursor up and down. Welcome to the future, it's mind blowing.

@cow1337killer3 commented on GitHub (Apr 29, 2024): Wow it's 2024 and we still can't move a terminal cursor up and down. Welcome to the future, it's mind blowing.

claunia commented

@zadjii-msft commented on GitHub (Apr 29, 2024):

@cow1337killer3 If you read the thread, you'll probably learn how that's a responsibility of the shell, not the terminal emulator itself. Up is pretty universally "go to the previous command in the history" across shells. And as discussed, we'd all love for the shells to support clicking to move the cursor in the prompt themselves, but there's myriad reasons why that's Hard. That's why the terminal added this feature to attempt to work around that issue.

@zadjii-msft commented on GitHub (Apr 29, 2024): @cow1337killer3 If you read the thread, you'll probably learn how that's a responsibility of the _shell_, not the terminal emulator itself. <kbd>Up</kbd> is pretty universally "go to the previous command in the history" across shells. And as discussed, we'd all _love_ for the shells to support clicking to move the cursor in the prompt themselves, but there's myriad reasons why that's **H**ard. That's why the terminal added this feature to attempt to work around that issue.

claunia commented

@vblazhkun commented on GitHub (Dec 12, 2024):

I guess the following behaviour is related to this feature. When I click with the LMB in any console app waiting for an input (ssh-keygen, cat, etc.) the whole screen is filled with ^[[D aka \x1b5b44:

And it infinitely fills up with just 2-3 consecutive clicks.

@vblazhkun commented on GitHub (Dec 12, 2024): I guess the following behaviour is related to this feature. When I click with the `LMB` in any console app waiting for an input (`ssh-keygen`, `cat`, etc.) the whole screen is filled with `^[[D` aka `\x1b5b44`: ![Image](https://github.com/user-attachments/assets/ef0c622e-244a-4e44-88d5-92977d8687ef) And it infinitely fills up with just 2-3 consecutive clicks.

claunia commented

@DHowett commented on GitHub (Dec 12, 2024):

Yes. If you don't have shell integration enabled to indicate where your prompt starts/ends and you are trying to use this feature (which is not enabled by default! for this reason!) you may see an unexpected spew of cursor positioning input.

@DHowett commented on GitHub (Dec 12, 2024): Yes. If you don't have shell integration enabled to indicate where your prompt starts/ends and you are trying to use this feature (which is not enabled by default! for this reason!) you may see an unexpected spew of cursor positioning input.

claunia commented

@vblazhkun commented on GitHub (Dec 12, 2024):

I have the shell integration enabled (all 4 escape sequences implemented) and its markers are visible on the right side of the screenshot.

@vblazhkun commented on GitHub (Dec 12, 2024): I have the shell integration enabled (all 4 escape sequences implemented) and its markers are visible on the right side of the screenshot.

claunia commented

@cow1337killer3 commented on GitHub (Jan 10, 2025):

@cow1337killer3 If you read the thread, you'll probably learn how that's a responsibility of the shell, not the terminal emulator itself. Up is pretty universally "go to the previous command in the history" across shells. And as discussed, we'd all love for the shells to support clicking to move the cursor in the prompt themselves, but there's myriad reasons why that's Hard. That's why the terminal added this feature to attempt to work around that issue.

Yup I understand that, but what I've been wondering is why there can't just be a fully-featured command line GUI. It would basically just be a textarea that relays every keystroke to an underlying terminal instance, and then outputs anything the terminal spits out into a display window. For example, someone could make an Electron app, code everything in JavaScript, then just have the app start its own PowerShell/terminal process that it relays input/output to between the GUI, using some kind of IPC.

I mean, I originally thought this was the design/intent of Windows Terminal (I'm not familiar with how it's constructed). If you just relay the keystrokes, translate mouse actions into cursor/selection commands, and relay the output, you can do anything you want with the GUI pretty easily. Like with Electron you can use the Selection API, listen for selectionchange events, then update the underlying terminal's cursor and selection using PSReadLine. Could also do drag and drop text.

@cow1337killer3 commented on GitHub (Jan 10, 2025): > [@cow1337killer3](https://github.com/cow1337killer3) If you read the thread, you'll probably learn how that's a responsibility of the _shell_, not the terminal emulator itself. Up is pretty universally "go to the previous command in the history" across shells. And as discussed, we'd all _love_ for the shells to support clicking to move the cursor in the prompt themselves, but there's myriad reasons why that's **H**ard. That's why the terminal added this feature to attempt to work around that issue. Yup I understand that, but what I've been wondering is why there can't just be a fully-featured command line GUI. It would basically just be a textarea that relays every keystroke to an underlying terminal instance, and then outputs anything the terminal spits out into a display window. For example, someone could make an Electron app, code everything in JavaScript, then just have the app start its own PowerShell/terminal process that it relays input/output to between the GUI, using some kind of IPC. I mean, I originally thought this was the design/intent of Windows Terminal (I'm not familiar with how it's constructed). If you just relay the keystrokes, translate mouse actions into cursor/selection commands, and relay the output, you can do anything you want with the GUI pretty easily. Like with Electron you can use the [Selection API](https://developer.mozilla.org/en-US/docs/Web/API/Selection), listen for `selectionchange` events, then update the underlying terminal's cursor and selection using [PSReadLine](https://learn.microsoft.com/en-us/powershell/module/psreadline/about/about_psreadline_functions?view=powershell-7.4#selection-functions). Could also do drag and drop text.

claunia commented

@jerch commented on GitHub (Jan 10, 2025):

@cow1337killer3

What you describe considers only the screen output side of a terminal ("GUI") and misses one crucial aspect - that part of a terminal is only a text canvas device for the active application (e.g. a shell), which is in fact in operative control. In that sense a terminal (emulator) is just a "textual graphic card", which receives drawing primitives for text output. Now you can ask yourself, whether you'd ask a graphics card vendor to implement drag&drop functionality, or ask instead the application, that is responsible for the content in the first place and knows all about the content's semantics.

@jerch commented on GitHub (Jan 10, 2025): @cow1337killer3 What you describe considers only the screen output side of a terminal ("GUI") and misses one crucial aspect - that part of a terminal is only a text canvas device for the active application (e.g. a shell), which is in fact in operative control. In that sense a terminal (emulator) is just a "textual graphic card", which receives drawing primitives for text output. Now you can ask yourself, whether you'd ask a graphics card vendor to implement drag&drop functionality, or ask instead the application, that is responsible for the content in the first place and knows all about the content's semantics.

claunia commented

@Cufoon commented on GitHub (Sep 3, 2025):

OK, I’ve read through the issue comments. I’m not particularly attached to using mouse clicks. In fact, I was thinking that we could provide a method—such as a multi-line command line editor—for editing long commands. For example, pressing Ctrl + Enter could pop up a dedicated command editor, and I could input the command after clicking "Confirm" or "Submit" in the pop-up. This approach would eliminate the need to manage mouse events and offer better compatibility. Additionally, it could be applied in any scenario that requires text input.

@Cufoon commented on GitHub (Sep 3, 2025): OK, I’ve read through the issue comments. I’m not particularly attached to using mouse clicks. In fact, I was thinking that we could provide a method—such as a multi-line command line editor—for editing long commands. For example, pressing Ctrl + Enter could pop up a dedicated command editor, and I could input the command after clicking "Confirm" or "Submit" in the pop-up. This approach would eliminate the need to manage mouse events and offer better compatibility. Additionally, it could be applied in any scenario that requires text input.

claunia commented

@sosnik commented on GitHub (Sep 3, 2025):

@Cufoon That would be a very hacky partial solution - one which we can already accomplish by copy-pasting the command line into a text editor or text input field (like opening another Windows Terminal with WIN+~). The UX would not be great.

On top of that, you wouldn't get any terminal completions in your multiline edit box, and you'd need to intelligently treat newlines and text-wrapping, as well. In many shells it is perfectly legitimate to enter a multiline command by leaving a \ at the end of the line. Does this 'multiline edit area' then strip all these slashes? But what if you're running a for-loop (etc) where the backslash is not needed?

@sosnik commented on GitHub (Sep 3, 2025): @Cufoon That would be a very hacky partial solution - one which we can already accomplish by copy-pasting the command line into a text editor or text input field (like opening another Windows Terminal with `WIN+~`). The UX would not be great. On top of that, you wouldn't get any terminal completions in your multiline edit box, and you'd need to intelligently treat newlines and text-wrapping, as well. In many shells it is perfectly legitimate to enter a multiline command by leaving a `\` at the end of the line. Does this 'multiline edit area' then strip all these slashes? But what if you're running a for-loop (etc) where the backslash is not needed?

claunia commented

@softworkz commented on GitHub (Sep 4, 2025):

I like the feature! But what I said above still stands:

Would you kindly help me out with what exactly I need to do to enable this for cmd and PowerShell without changing anything else (it's all at defaults)?
And maybe add it to the docs page to which the text about the setting is linking to but which doesn't even mention it and neither discriminates which modification is needed for which feature exactly.

It's still unclear what exactly is needed for this feature to work properly and what not. I understand that configuration is required from several sides, but this is not directly clear for many users and especially it's hard to understand why and when the behavior is not exactly as expected.

As far as I understand, the feature requires prompts to be marked in order to determine whether a mouse click is inside or outside of a prompt.
BUT: When prompts are not being marked - the feature is still acting upon mouse clicks - but with side effects:

When scrolling up and trying to select a range of text there, the mouse-down activates the feature and you are getting scrolled-down back to the prompt - making it impossible to select that range of text you wanted to select
When clicking during an ongoing command, the screen can get filled with control chars like ^[[D
(like @vblazhkun reported above)

Suggestion

In those cases, the feature implementation is surely aware that there is no prompt marking enabled.
So it should display a warning (once per session) like:

"The cursor repositioning feature is enabled, but there's no prompt marking. Without prompt marking, you may experience undesired side-effects like [...]. Please make sure to enable 'autoMarkPrompts' or adjust the prompt according to the documentation at https://....."

Improve Documentation

The documentation currently states that the "reposition cursor" feature requires "Shell Integration" to be enabled.

In order for this setting to work, you will need to enable shell integration in your shell.

The Shell Integration page is a long article, but from my experience, it is NOT REQUIRED to do all the things that are described on this page.

All I had to do was:

Add "autoMarkPrompts": true to the settings.json file
Run setx PROMPT $e]133;D$e\$e]133;A$e\$e]9;9;$P$e\$P$G$e]133;B$e\ for CMD

I didn't need to make any changes to any powershell profile or bash profile files on WSL

It would be great when the documentation would be more clear about what's really needed and that those painful profile changes are not required at all.

Thanks

@softworkz commented on GitHub (Sep 4, 2025): I like the feature! But what I said above still stands: > Would you kindly help me out with what exactly I need to do to enable this for cmd and PowerShell without changing anything else (it's all at defaults)? > And maybe add it to the docs page to which the text about the setting is linking to but which doesn't even mention it and neither discriminates which modification is needed for which feature exactly. It's still unclear what exactly is needed for this feature to work properly and what not. I understand that configuration is required from several sides, but this is not directly clear for many users and especially it's hard to understand why and when the behavior is not exactly as expected. As far as I understand, the feature requires prompts to be marked in order to determine whether a mouse click is inside or outside of a prompt. BUT: When prompts are not being marked - the feature is still acting upon mouse clicks - but with side effects: - When scrolling up and trying to select a range of text there, the mouse-down activates the feature and you are getting scrolled-down back to the prompt - making it impossible to select that range of text you wanted to select - When clicking during an ongoing command, the screen can get filled with control chars like `^[[D` (like @vblazhkun reported [above](https://github.com/microsoft/terminal/issues/8573#issuecomment-2539899248)) ### Suggestion In those cases, the feature implementation is surely aware that there is no prompt marking enabled. So it should display a warning (once per session) like: "The cursor repositioning feature is enabled, but there's no prompt marking. Without prompt marking, you may experience undesired side-effects like [...]. Please make sure to enable 'autoMarkPrompts' or adjust the prompt according to the documentation at https://....." ### Improve Documentation The documentation currently states that the "reposition cursor" feature requires "Shell Integration" to be enabled. > In order for this setting to work, you will need to enable [shell integration](https://learn.microsoft.com/en-us/windows/terminal/tutorials/shell-integration) in your shell. The [Shell Integration](https://learn.microsoft.com/en-us/windows/terminal/tutorials/shell-integration) page is a long article, but from my experience, it is NOT REQUIRED to do all the things that are described on this page. All I had to do was: - Add `"autoMarkPrompts": true` to the settings.json file - Run `setx PROMPT $e]133;D$e\$e]133;A$e\$e]9;9;$P$e\$P$G$e]133;B$e\` for CMD I didn't need to make any changes to any powershell profile or bash profile files on WSL It would be great when the documentation would be more clear about what's really needed and that those painful profile changes are not required at all. Thanks

claunia commented

@Cufoon commented on GitHub (Sep 4, 2025):

@Cufoon That would be a very hacky partial solution - one which we can already accomplish by copy-pasting the command line into a text editor or text input field (like opening another Windows Terminal with WIN+~). The UX would not be great.

On top of that, you wouldn't get any terminal completions in your multiline edit box, and you'd need to intelligently treat newlines and text-wrapping, as well. In many shells it is perfectly legitimate to enter a multiline command by leaving a \ at the end of the line. Does this 'multiline edit area' then strip all these slashes? But what if you're running a for-loop (etc) where the backslash is not needed?

Indeed, you are quite right. This is a rather hacky approach and it does lead to the inability to perform command auto-completion. Regarding the issue you mentioned about multi-line backslashes, it could be automatically converted to a single line or retain the backslashes after confirmation in this "editor". This is a matter of choice in behavior. As for the auto-completion issue, the need to switch the cursor position by mouse click often arises when I have a very long command and there is a problem at a certain position that needs to be modified, or when I have a batch of commands where only the beginning parts are different. In such cases, mouse clicking rather than holding down the left and right arrow keys, or using the vim mode for editing, is the fastest and most convenient way. However, from the context of this discussion, it seems that supporting this feature requires the shell and terminal to work together well. In the case where such cooperation is difficult to achieve, I think providing such a method is not a bad idea. It's like a single-line text box where we can allow it to pop up a large input box for content entry. I think this interaction is quite reasonable. Of course, I have methods, such as copying the command to a real editor for editing and then copying it back to execute. This is certainly feasible. In the past few years, I have always copied a long command to VSCode, edited it there, and then copied it back to execute. But I'm fed up with this. The experience is too bad. I don't want to shuttle between two software, and I don't want to close the temporary file in VSCode when I close VSCode. This is too bad. If that's the case, I might as well just use the built-in terminal in VSCode.

@Cufoon commented on GitHub (Sep 4, 2025): > [@Cufoon](https://github.com/Cufoon) That would be a very hacky partial solution - one which we can already accomplish by copy-pasting the command line into a text editor or text input field (like opening another Windows Terminal with `WIN+~`). The UX would not be great. > > On top of that, you wouldn't get any terminal completions in your multiline edit box, and you'd need to intelligently treat newlines and text-wrapping, as well. In many shells it is perfectly legitimate to enter a multiline command by leaving a `\` at the end of the line. Does this 'multiline edit area' then strip all these slashes? But what if you're running a for-loop (etc) where the backslash is not needed? Indeed, you are quite right. This is a rather hacky approach and it does lead to the inability to perform command auto-completion. Regarding the issue you mentioned about multi-line backslashes, it could be automatically converted to a single line or retain the backslashes after confirmation in this "editor". This is a matter of choice in behavior. As for the auto-completion issue, the need to switch the cursor position by mouse click often arises when I have a very long command and there is a problem at a certain position that needs to be modified, or when I have a batch of commands where only the beginning parts are different. In such cases, mouse clicking rather than holding down the left and right arrow keys, or using the vim mode for editing, is the fastest and most convenient way. However, from the context of this discussion, it seems that supporting this feature requires the shell and terminal to work together well. In the case where such cooperation is difficult to achieve, I think providing such a method is not a bad idea. It's like a single-line text box where we can allow it to pop up a large input box for content entry. I think this interaction is quite reasonable. Of course, I have methods, such as copying the command to a real editor for editing and then copying it back to execute. This is certainly feasible. In the past few years, I have always copied a long command to VSCode, edited it there, and then copied it back to execute. But I'm fed up with this. The experience is too bad. I don't want to shuttle between two software, and I don't want to close the temporary file in VSCode when I close VSCode. This is too bad. If that's the case, I might as well just use the built-in terminal in VSCode.

claunia commented