Allow binding side modifier keys

[eugenesvk]

keybind = left_shift+a=open_config is rejected despite the fact that it's in

The set of possible keys is currently only available for reference by viewing the source code. This list is derived from Chromium's keycodes and is closely associated with keys that have associated USB HID codes.

[mitchellh]

Accepted.

Ghostty is already aware of left/right modifiers so expanding this to bindings should not be difficult.

[manosriram]

Working on this, can someone assign this to me?

[AnthonyZhOon]

Documenting some research on this:

The current behaviour is that left_control and other sided input can be parsed as an activation key but not a modifier.
Such that,
keybind = left_control=new_tab works by treating left_control as the pressed key
keybind = left_control+a=new_tab does not parse as it sets the activation to left_control then tries to overwrite it with a. Instead of treating left_control as a modifier in this context
src/input/Binding.zig#L1106
This will require special-casing {left, right}_* modifiers to allow the activated key to be overwritten.

Parsing as a modifier requires adding to the modifier parsing section.
Additionally, to distinguish a left_* right_* or plain ctrl the Side enum needs to support { either, left, right}, there are still bits left in the Mods struct to accommodate this without increasing backing size. The default initialisation should be either.

Then the Set used to lookup mappings between Triggers and Actions needs to consider the now distinguishing sides field in lookup, considering hashing and equality checks to avoid collisions between a left_control and right_control modifier.
hashing/binding related comparisons should modify Mod.binding(), this will modify Trigger.hash()

Modifying the terminal inspector display the side of modifiers is a bonus and can help debugging.

It looks like there's code in the swift and gtk apprts for describing sided input, Ghosttty.Input.swift gtk/key.zig

[AnthonyZhOon]

Representing a Trigger internally can support this. However the APIs for existing apprts do not provide indicators whether a modifier (shift, ctrl, alt, super) came from which side of {left,right}.

Our gtk key callback is bound here

ghostty/src/apprt/gtk/Surface.zig

Line 592 in f1f1120

_ = c.g_signal_connect_data(ec_key_press, "key-pressed", c.G_CALLBACK(&gtkKeyPressed), self, null, c.G_CONNECT_DEFAULT);

and use the gtk_mods to determine the active modifiers for a non-modifer key.

Instrumenting the terminal inspector we see:

We can write config that uses specifically lctrl, lshift or rshift etc pretty simply, but we can't tell whether input is side-specific such as if a Shift modifier on 'a' was from left_shift or right_shift currently.

APIs without side information:

• libX11
• GTKD
• AppKit

APIs that can query key-state (including sides):

• win32

To support this, I think we need to maintain our own key-state, at least for modifiers, accumulating over key-event stream given by the existing APIs instead of relying on toolkit APIs.

@mitchellh This doesn't seem as simple as expected, can you review if we still want to implement?