Allow mouse clicks to reposition cursor by emitting cursor key sequences

[sosnik]

Description of the new feature/enhancement

Windows Terminal version: 1.4.3243.0
Windows Version: Microsoft Windows [Version 10.0.19042.630]
Also using:
    GNU bash, version 4.4.12(3)-release (x86_64-unknown-cygwin) under cygwin
    GNU bash, version 4.4.23(2)-release (x86_64-pc-msys) under msys2
    GNU bash, version 5.0.17(1)-release (x86_64-pc-linux-gnu) under Ubuntu 20.04 WSL 2

It is not possible to place the cursor with the mouse in any of these shells under Windows Terminal. It is, however, quite possible to do this when running bash with msys2, cygwin or wsl on mintty (or WSL terminal).

This issue was discussed in #4268, where it was dismissed because I'm not sure I know of any shell application that actually supports that tbh.. This is patently not the case as it is supported in the integrations between bash and mintty (and the same bash as used by mintty is being loaded in Windows Terminal).

Mouse support was tracked in #376, #545 and #5177. There was a pull request in #/pull/4859 to close some of these issues, however cursor placement still doesn't appear to work in the applications I listed.

[zadjii-msft]

Okay which terminal emulator are you seeing this behavior in? I just tried a plain old conhost with Ubuntu20.04, and I'm not seeing bash request mouse mode.

Same thing with Msys

Both these have pretty vanilla setups.

Is there something that you have to set in your bashrc to configure bash to request mouse mode? Mouse input is a little complicated here. Win32 mouse input doesn't work in the Windows Terminal, but VT-style mouse input should work.

[sosnik]

cygwin, msys, msys2, and wsltty all use mintty as the terminal emulator. As far as I am aware, there's nothing special in my bash dotfiles. Here is a gif of mouse positioning in cygwin:

Here's one for msys2:

And one for Ubuntu WSL running under mintty:

mintty itself has a setting to place mouse cursor with clicks:

To access this settings pane: Click Title bar of application running under mintty (e.g. msys) -> Go to Properties > Go to Mouse Tab

I am assuming this is a feature provided by mintty and not necessarily by bash (compiled for these platforms) because opening bash.exe from within cmd (conhost) or through the Windows Terminal application does not produce this result. One would assume that if this was functionality internal to bash, it would work in those other requirements.

Therefore, I believe this should be a feature that can be implemented within Windows Terminal. This is the mintty repo: https://github.com/mintty/mintty

[skyline75489]

Yeah the "Clicks place command line cursor" is the key. I can confirm this with wsltty.

[skyline75489]

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.

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

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

[zadjii-msft]

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"

[malxau]

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.

[DHowett]

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.

[malxau]

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

[sosnik]

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.

[DHowett]

intercepts scroll events

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

[dkaloc]

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.

[dkaloc]

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

[christianparpart]

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. :-)

[malxau]

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

[christianparpart]

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]

[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. :)

[zadjii-msft]

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

[j4james]

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.

[softworkz]

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

[DHowett]

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:

[softworkz]

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.

[zadjii-msft]

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.

[softworkz]

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.

[j4james]

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.

[KalleOlaviNiemitalo]

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?

[zadjii-msft]

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.

[j4james]

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.

[zadjii-msft]

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

[con-dog]

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

[Suncatcher]

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

[zadjii-msft]

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.

[christianparpart]

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

[zadjii-msft]

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.

[softworkz]

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.

[zadjii-msft]

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!

[softworkz]

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" :-)

[DHowett]

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

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

[zadjii-msft]

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

[christianparpart]

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

[zadjii-msft]

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?

[j4james]

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.

[GaryAtlan82]

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.

[zadjii-msft]

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.

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.

[j4james]

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

[softworkz]

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.

[zadjii-msft]

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?

[christianparpart]

@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
• Text Selection Tracking Extension

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 :)

[softworkz]

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.

[sarim]

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