Problems with alt-click cursor move feature implementation

[aswinmprabhu]

I had initially created the discussion at #4043 because I wanted the alt-click cursor move feature without shell integration (e.g., ssh).

After playing around with it, I think there are other problems with the existing implementation? --

Problem 1: We are using up/down arrow keys to achieve vertical movement along the y-axis. I don't think this is supported on bash: https://www.gnu.org/software/bash/manual/bash.html#Sample-Init-File. This leads to the up arrow key being interpreted as previous-history instead of up-line in bash which changes what you have typed and replaces it with your previous command.

Steps to reproduce (check the demo for details):

1. Open a bash shell. I used bash 5.2.37 from homebrew.
2. Source the shell integration script as described here: https://ghostty.org/docs/features/shell-integration#manual-shell-integration-setup. My window was 106c x 55 r with font size of 14.
3. Paste in Lorem ipsum dolor sit amet, consectetur adipiscing elit. Sed lobortis id magna non suscipit. Sed auctor sit amet dolor eu commodo. Maecenas molestie, lacus sit amet ornare ultrices, nisi lorem sollicitudin dolor, a pharetra nulla dui vitae eros. Orci varius natoque penatibus et magnis dis parturient montes, nascetur ridiculus mus.
4. Click on any line of the lorem prompt that is not the last line. You should see the previous command you executed from your history.

Problem 2: Even for shells like zsh where the up arrow is mapped to up-line-or-history / up-line-or-search, if we have a long wrapped prompt, vertical movement doesn't work because (I think) zsh thinks you are already at the top line. And then it tries to search up your history.

Steps to reproduce:
Same as bash but the result should be that cursor doesn't move where you want it to. (History search shouldn't work unless you have a lorem suffixed command you executed earlier).

Potential Solution?
As pitched in #4043, use ONLY the left/right arrow keys for alt-click navigation (leveraging the column count state). This lets us enable this feature without shell integration as well. This has the downside of not working well with multiline editing in zsh etc.
Code is pushed here:
aswinmprabhu@7da8167

Demo showing the problem and fix:
Left is the 1.0.1 stable build and right is the build from my branch. Bash and zsh are shown.

Screenshare.-.2025-01-20.10_52_08.PM.mp4

[mitchellh]

Thanks for the thoughtful write-up. I specifically implemented it this way most likely because I use a multiline editing shell (fish). I wonder if we should make the cursor move feature shell-aware so we can switch between using up/down or purely left/right. We could easily determine the shell from shell integration (and we already do via binary name heuristics though we don't currently depend on that for any other functionality).

[aswinmprabhu]

Thanks for checking this out.
I just tried fish. Looks like vertical movement doesn't work on fish as well if your prompt is long and wrapped instead of multi-line. It would be a question of whether we want the alt-click movement to work with long-wrapped prompts or with long multi-line prompts. I run into the former more often than the latter. Also, this gives us the ability to enable alt-click without shell integration, which I think is very nice. Making this more shell-aware doesn't solve problem 2 and doesn't give us this added benefit.

[aswinmprabhu]

#2582 Looks related @mitchellh ?