macOS: respond to standard keybindings for cursor manipulation

[BernieSumption]

From a UX perspective this is related to #2526 but I think it's a different request technically so I'm submitting a new issue

In almost every text field in macOS applications the following keybindings apply:

• LeftArrow / RightArrow: move cursor one character left / right (This is the only one Ghostty does)
• Cmd+LeftArrow / Cmd+RightArrow : move cursor to start / end of current line (if text is soft wrapping, line is the wrapped on-screen line, not the newline character)
• Option+LeftArrow / Option+RightArrow: move cursor to next / previous word
• Shift+ any of the above: move the cursor in the same way and create or extend a text selection from the previous to the new cursor position

Using any of these keys (and they are very much in my muscle memory) in Ghostty prints codes to the screen e.g. ;9D for Command+LeftArrow.

The Mac only terminal partially implements these shortcuts, it does the most useful ones Option+LeftArrow / Option+RightArrow which I use all the time for editing commands, but doesn't do the rest.

[mitchellh]

This isn’t a terminal responsibility. This is a shell responsibility or further program.

Terminals take keyboard input and encode it into some textual protocol such as Kitty keyboard protocol. The running program moves the cursor. Terminals don’t and can’t move the cursor; they only move it in response to a request from the running program.

Please report this upstream to your shell. Ghostty encodes all input unambiguously so they can support this.

Also note there are some other issues where people have used the text keyboard action to hack this in by having these inputs quack certain control codes to trick readline enabled programs into doing this.

As a final note, issues aren’t where feature requests are made. Please open a discussion next time! Thank you

[BernieSumption]

Thanks for the explanation.

I'm using zsh on both Ghostty and Apple's Terminal, and the behaviour for Option+LeftArrow is different. In Apple Terminal it sends the cursor back one word, in Ghostty it prints ;3D.

Is that an issue with Ghostty?

[mitchellh]

No, Ghostty supports a newer keyboard encoding that zsh doesn't support: https://www.leonerd.org.uk/hacks/fixterms/

This is a zsh bug.

There are multiple help threads and issues that show how to workaround this and we're actively discussing just ignoring that part of fixterms as well in the zero config discussion.

[mitchellh]

Also note when I say "newer", its still over 20 years old.

[BernieSumption]

OK I'll go get myself a better shell. Thanks for taking the time to educate me!

[mitchellh]

Heh, it's reasonable for zsh to use the "traditional" encoding style. The workarounds in the other issues work well enough, its only a few lines of config!

[BernieSumption]

Posting this here in case anyone finds this issue through search. There are discussions in Discord about how to configure this behaviour, and the Ghostty config that gets me the cursor movement behaviour I want with zsh is:

macos-option-as-alt = true
keybind = cmd+right=text:\x05
keybind = cmd+left=text:\x01
keybind = alt+left=esc:b
keybind = alt+right=esc:f