Question/discussion: Key tables should be allowed to target the whole window instead of just the surface they were activated on

[iniw]

Issue Description

My first idea with key tables was to make a hydra-mode type keybind scheme:

keybind = split/
keybind = split/s=new_split:down
keybind = split/v=new_split:right
keybind = split/h=goto_split:left
keybind = split/j=goto_split:down
keybind = split/k=goto_split:up
keybind = split/l=goto_split:right
keybind = split/z=toggle_split_zoom
keybind = split/catch_all=ignore
keybind = split/escape=deactivate_key_table
keybind = super+s=activate_key_table:split

The idea is that pressing super+s gets you in "split mode" and you can control/navigate splits freely - then exit it by pressing escape. Here's a similar one for tabs:

keybind = tab/
keybind = tab/n=new_tab
keybind = tab/d=close_tab
keybind = tab/h=previous_tab
keybind = tab/l=next_tab
keybind = tab/catch_all=ignore
keybind = tab/escape=deactivate_key_table
keybind = super+t=activate_key_table:tab

These are wonderful and would work great, if it weren't for the fact that the key tables are applied to the surface, not to the window. So, for example, when I press super+t -> n, to create a new tab, I actually can't press h to go the previous tab, because the key table is only active on the surface it was created on.

This also makes the split navigation completely unusable. The idea is to press super+s and use h/j/k/l to move between splits, but that doesn't work because only the original split keeps the key table.

Is this a design decision or just an oversight? IMO making the active key table a property of the whole window instead of the surface it was created on would make more sense.

Another idea is to give activate_key_table an extra (optional) parameter to select the "level" it should be applied to. For example:

keybind = super+s=activate_key_table:split:{window|tab|split}

Expected Behavior

I would've expected key tables to apply to the whole window, or at least be configurable to do so, which would greatly expand it's use cases.

Actual Behavior

Key tables are only active in the surface they were created on.

Reproduction Steps

~

Ghostty Logs

No response

Ghostty Version

Ghostty 1.3.0-main+1fa6641a6

Version
  - version: 1.3.0-main+1fa6641a6
  - channel: tip
Build Config
  - Zig version   : 0.15.2
  - build mode    : .ReleaseFast
  - app runtime   : .none
  - font engine   : .coretext
  - renderer      : renderer.generic.Renderer(renderer.Metal)
  - libxev        : kqueue

OS Version Information

MacOS 26.2

(Linux only) Display Server

None

(Linux only) Desktop Environment/Window Manager

No response

Minimal Ghostty Configuration

keybind = split/
keybind = split/s=new_split:down
keybind = split/v=new_split:right
keybind = split/h=goto_split:left
keybind = split/j=goto_split:down
keybind = split/k=goto_split:up
keybind = split/l=goto_split:right
keybind = split/catch_all=ignore
keybind = split/escape=deactivate_key_table
keybind = super+s=activate_key_table:split

Additional Relevant Configuration

No response

I acknowledge that:

• I have reviewed the FAQ and confirm that my issue is NOT among them.
• I have searched the Ghostty repository (both open and closed Discussions and Issues) and confirm this is not a duplicate of an existing issue or discussion.
• I have checked the "Preview" tab on all text fields to ensure that everything looks right, and have wrapped all configuration and code in code blocks with a group of three backticks (```) on separate lines.

[mitchellh]

I think what you're asking was a limitation that was explicitly noted in the chaining issue, so it's worth bringing back up here since it also affects key tables: all actions impact the originating surface. It's not exactly the same, but I think if you step back, it's a very closely related issue such that we should at least be thinking about both when resolving this.

I don't have a solution, just adding some more context.

[danielwe]

To flesh out this context with a concrete example: my first idea with chained keybinds was to modify Cmd+, (open config) to run ghostty +edit-config in a new tab. I wish the following worked, but because of this limitation, it doesn't:

keybind = cmd+,=new_tab
keybind = chain=text:ghostty +edit-config\n

[devxoul]

Yeah I was really happy when I saw #10015 got merged but sadly I couldn't use this for my scenario:

• cmd+t for new $HOME tab
• cmd+shift+t for $CWD tab

What I tried was like:

window-inherit-working-directory = true
keybind = cmd+shift+t=new_tab

keybind = cmd+t=new_tab
keybind = chain=text:cd ~\n  # <-- this goes into the previous tab
keybind = chain=clear_screen