Support text cursor moving by mouse clicking

[ModProg]

Is your feature request related to a problem? Please describe. When havin long or multiline command lines it is time consuming to move to the correct position via keyboard

Describe the solution you'd like Have a keycombination where you can click at a position, and if possible, the curser will move there through key input.

Describe alternatives you've considered I though about implementing that via config, but there is no way to tell the mouse position and the current cursor position so this is not possible.

Additional context There are some terminals that have this: http://domterm.org/Tips.html#move-cursor-with-mouse https://apple.stackexchange.com/questions/42825/option-click-in-iterm

Possible issues At we should move horizontally first and then vertically as vertical movement traverses history in a lot of shells.

[ghost]

Thinking aloud from the peanut gallery:

• A trivial implementation would be to continue sending left-arrow until the cursor is at the mouse position (yay), the cursor stops moving (at beginning of line, or there is garbage on screen such that left arrow cannot get there), or the cursor goes too far (oops). But what if the network pauses for 3 seconds in between the left-arrow and the new cursor location?
• What if a line has mixed-width codepoints / gramene clusters?
• What if there is a vertical split multiplexer in the way (e.g. tmux)? How would wezterm be able to calculate the number of left-arrows to send when it doesn't know where the multiplexer's terminals are on screen in relation to each other? (This gets much hairier too when you add floating partially-obscured terminals ala jexer.)
• What about applications that do full-screen but don't actually switch to the alternate screen buffer? What about the "command-line" apps that would benefit from this, but ARE using the alternate screen buffer (e.g. IRC client)?
• Is there a means to advertise this feature to the applications? CSI 15 u / CSI 15 ; 2 u is not a standard xterm sequence.

[wez]

I'd be inclined to use the existing semantic zones concept (OSC 133, described in https://gitlab.freedesktop.org/Per_Bothner/specifications/blob/master/proposals/semantic-prompts.md which also originates from DomTerm) to demark the input region, then "simply" use that to compute the number of left or right moves to get to the appropriate place and just send that many moves without waiting to see how the cursor really moves.

There are still potential problems with tmux/jexer that might need an alternative/expanded OSC 133 sequence to define the input region, maybe using an ID similar to how OSC 8 logically connects a hyperlink in similar situations.

[khuongduybui]

I'm not entirely sure how https://www.warp.dev/ does it, but their text-editing capabilities (especially multi-line and multi-cursor) look very compelling.

Demo: https://www.loom.com/share/1517049fefc34227bf1abaf19cc7e6ea?t=1

[wez]

My educated guess is that warp use OSC 133 style escapes that indicate when a prompt is in use, and then they replace your shell prompt with their own editor.

My first-hand experience with https://fig.io/ is that they also use OSC 133 style escapes (but with their own OSC code) together with an additional PTY process that wraps around the other side of the shell and then they use the macOS accessibility API to augment the existing shell prompt with suggestions.

[khuongduybui]

OR, a radical idea: We render the terminal (and the prompt) in a top pane We have a real editor to craft the new command in a bottom pane

I really doubt if that's exactly what warp does. If you watch the demo on their front page, especially here https://www.warp.dev/#:~:text=Input%20that%20feels%20like%20a%20code%20editor you will probably have the same guess

[wez]

To be clear: I personally have very little interest in building an alternative editor for this sort of thing, as there are a lot of complexities and product surface: the shell has had decades of work on programmable command line completion and highlighting and other functions that require access to the host on which the shell is running. There's a lot of work to replicate what the shell does to a degree where it wouldn't be a regression over what we currently support by simply not trying to get in the way :)

It's also not something that I need for myself: I know how to tell my shell's line editor to open my favorite editor to edit a multi-line command when I need it (https://unix.stackexchange.com/questions/6620/how-to-edit-command-line-in-full-screen-editor-in-zsh has examples for zsh for example), so spending my time on that doesn't benefit me personally.

[khuongduybui]

I totally agree. And that's not the point of this issue either. I was simply pointing out how others might have implemented the mouse support.

[digitallyserviced]

I totally agree. And that's not the point of this issue either. I was simply pointing out how others might have implemented the mouse support.

:man_shrugging: People use the mouse in a terminal? huh? lol

[khuongduybui]

I totally agree. And that's not the point of this issue either. I was simply pointing out how others might have implemented the mouse support.

🤷‍♂️ People use the mouse in a terminal? huh? lol

There are cases where you mostly reuse past commands and have to make some minor changes, it's faster to move the cursor to the editing position with the mouse on one hand and make the small modifications with the other hand. Depending on your job sometimes you end up doing that very frequently.

[AutumnMeowMeow]

OR, a radical idea: We render the terminal (and the prompt) in a top pane We have a real editor to craft the new command in a bottom pane

Something similar to this was implemented by several BBS-era programs. They called it split-screen.

Example:

[mcarans]

Konsole has this feature now as well

[robbinhan]

I wish could have this features.

[tmccombs]

Kitty also has this feature. I'm pretty sure it also uses OSC 133