Sequenced Keybindings

[mitchellh]

Fixes #1420

This adds support for sequenced keybinds. In other programs these are sometimes called key chords, leader sequence, key tables, etc (these are also all slightly different concepts if you really dig into the details, but in the same category). Effectively, they're the ability to specify a keybinding not happen unless a sequence of separate key inputs is given. As examples, these are commonly present in tmux, emacs, etc.

Sequenced key binds use the existing keybind configuration, but introduce a new symbol > as a way to separate the sequenced triggers. For example, ctrl+a>b=text:hello will write the text "hello" after the users presses ctrl+a and then b. Some behavioral details (in the documentation, too):

• Ghostty will wait an indefinite amount of time for valid sequences. If you type ctrl+a and you have any children defined, Ghostty will wait forever for an input.
• Ghostty will flush all inputs once an invalid sequence is given. For example, if you bind ctrl+a>b and type ctrl+a>c, then Ghostty will encode and send ctrl+a followed by c to the pty.
• Ghostty will consume all inputs on valid sequences. If you bind ctrl+a>b and trigger it, both ctrl+a and b are consumed.
• The previously existing unconsumed: feature will apply to the full sequence. If you bind unconsumed:ctrl+a>b then triggering the sequence will encode and flush both ctrl+a and b. There is no way today to only unconsumed a partial sequence.
• If a prefix in a sequence is previously bound, the sequence will override the previous binding. For example, if ctrl+a is bound to new_window and ctrl+a>n is bound to new_tab, pressing ctrl+a will do nothing.
• Adding to the above, if a previously bound sequence prefix is used in a new, non-sequence binding, the entire previously bound sequence will be unbound. For example, if you bind ctrl+a>n and ctrl+a>t, and then bind ctrl+a directly, both ctrl+a>n and ctrl+a>t will become unbound.

Future Work

• This PR does not include UI feedback that a keyboard sequence is present/pending. This creates an awkward and somewhat dangerous user experience today: Ghostty can be waiting for a sequence and it may seem like Ghostty ignored your input. There is no feedback to show this state. I noted this in Allow multi-key keybinds #1420 and plan to integrate this feature after.
• The +show-keybinds CLI action silently ignores key sequences. cc @rockorager