This adds some new special case handling for key sequences when an
unbound keyboard input is received. If the current keybinding set scope
(i.e. active tables) has a `catch_all` binding that would `ignore`
input, then the entire key sequence is dropped.
Normally, when an unbound key sequence is received, Ghostty encodes it
and sends it to the running program.
This special behavior is useful for things like Vim mode which have `g>g`
to scroll to top, and a `catch_all=ignore` to drop all other input. If
the user presses `g>h` (unbound), you don't want `gh` to show up in your
terminal input, because the `catch_all=ignore` indicates that the user
wants that mode to drop all unbound input.
Fixes#2127
This adds a UI similar to macOS to show the current state of key
sequences and/or key tables.
https://github.com/user-attachments/assets/4399d2af-a88c-4b70-922b-7727dc4d2053
**AI disclosure:** AI was used for various things, but I did write most
of the code myself, especially around the memory management of
properties since agents can't get that quite right yet. 😄
Add a unit test to prevent regressions in our failure state.
For example, we always want to set GHOSTTY_SHELL_FEATURES, even if
automatic shell integration fails, because it's also used for manual
shell integration (e.g. #5048).
Add a unit test to prevent regressions in our failure state.
For example, we always want to set GHOSTTY_SHELL_FEATURES, even if
automatic shell integration fails, because it's also used for manual
shell integration (e.g. #5048).
> **Note**: This is a re-submission of #9952, which was closed in favor
of #9975. However, as noted in my [comment on
#9975](https://github.com/ghostty-org/ghostty/pull/9975#issuecomment-3677916608),
the issue still persists.
## Summary
- Fix `window-position-x/y` not being applied when `window-width/height`
is also configured
## Problem
When both `window-position-x/y` and `window-width/height` are
configured, the window position was not being applied correctly. The
window would appear near the center of the screen instead of the
specified position.
This worked correctly in v1.2.3 but regressed afterwards.
## Root Cause
This is a regression introduced in c75bade89 (#9747).
The commit refactored the default size logic from a computed `NSRect?`
property to a `DefaultSize` enum with `.frame` and
`.contentIntrinsicSize` cases.
**Before (working):**
```swift
private var defaultSize: NSRect? {
// ... calculate frame ...
return adjustForWindowPosition(frame: frame, on: screen) // ← position was applied
}
```
**After (broken):**
```swift
enum DefaultSize {
case frame(NSRect)
case contentIntrinsicSize
func apply(to window: NSWindow) {
case .contentIntrinsicSize:
window.setContentSize(size)
window.constrainToScreen()
// ← adjustForWindowPosition call was lost
}
}
```
When `window-width/height` is configured, the `.contentIntrinsicSize`
case is used. This case only called `setContentSize` and
`constrainToScreen`, but did not apply the window position adjustment.
## Why This Fix is Correct
`DefaultSize.apply()` is intentionally **not** responsible for
position—it only handles **size**:
1. `apply()` is also called from `returnToDefaultSize(_:)` menu action
2. When user triggers "Return to Default Size", only the **size** should
reset—**not the position**
3. If we added position logic inside `apply()`, the window would
unexpectedly jump back to its initial position
Therefore, position adjustment belongs **outside** of `apply()`,
specifically during initial window setup in `windowDidLoad`.
## Fix
Call `adjustForWindowPosition` after applying the content intrinsic size
to ensure the window position is correctly set during initial window
creation.
Closes#9995
**Problem**: `ghostty +list-keybinds` doesn't display bindings from key
tables.
**Solution**: Iterate over `keybinds.tables` and collect bindings from
each table, prefixing them with `table_name/` in the output. Bindings
are sorted with default bindings first, then table bindings grouped
alphabetically by table name.
https://github.com/user-attachments/assets/de73b66a-fc23-4913-a083-7a4aa992c5ec
> _My theme is "Monokai Pro Octagon" which makes `blue` → `orange`_
<details>
<summary>Default theme output</summary>
<img width="942" height="824" alt="Screenshot 2025-12-23 at 08 34 10"
src="https://github.com/user-attachments/assets/21b3a746-930c-4795-b538-f92455cf5fa5"
/>
</details>
I chose `8` (for `table_style`) since table names are secondary (thus,
dim gray color) and color is distinct without overpowering. Obviously,
open to whatever is preferred.
**Testing**: Manual verification with configs containing multiple key
tables, chained bindings within tables, and mixed default/table
bindings.
---
> **AI Disclosure**: Claude Code for research and review. All code typed
by me.
- Display keybindings grouped by their source table, with table name as prefix
- Sort default bindings before table bindings, maintaining visual hierarchy
- Support keybindings defined in key tables alongside default bindings
- Enable users to discover all available keybindings across the entire config
Fixes#10020
This improves parsing key tables so that the following edge cases are
now handled correctly, which were regressions from prior tip behavior:
- `/=action`
- `ctrl+/=action`
- `table//=action` (valid to bind `/` in a table)
- `table/a>//=action` (valid to bind a table with a sequence)
Fixes#10020
This improves parsing key tables so that the following edge cases
are now handled correctly, which were regressions from prior tip
behavior:
- `/=action`
- `ctrl+/=action`
- `table//=action` (valid to bind `/` in a table)
- `table/a>//=action` (valid to bind a table with a sequence)
Fixes#9961
This implements chained keybinds as described in #9961.
```
keybind = ctrl+shift+f=toggle_fullscreen
keybind = chain=toggle_window_decorations
```
These work with tables and sequences. For tables, the chain is unique
per table, so the following works:
```
keybind = foo/ctrl+shift+f=toggle_fullscreen
keybind = foo/chain=toggle_window_decorations
```
For sequences, it applies to the most recent sequence:
```
keybind = ctrl+b>f=toggle_fullscreen
keybind = chain=toggle_window_decorations
```
## TODO
Some limitations to resolve in future PRs (make an issue) or commits:
- [x] GTK: Global shortcuts cannot be chained: #10019
- [x] Inspector doesn't show chained keybinds
- [x] `+list-keybinds` doesn't show chains
**AI disclosure:** AI helped write tests, but everything else was
organic. AI did surprisingly bad at trying to implement this feature, so
I threw all of its work away! 😄
When window-width/height is configured, the window size is set via
setContentSize in windowDidLoad. However, window-position-x/y was not
being applied after this resize, causing the window to appear at an
incorrect position.
This was a regression introduced in c75bade89 which refactored the
default size logic from a computed NSRect property to a DefaultSize
enum. The original code called adjustForWindowPosition after calculating
the frame, but this was lost during the refactoring.
Fixes the issue by calling adjustForWindowPosition after applying
contentIntrinsicSize to ensure window position is correctly set.
Our automatic shell integrations require certain resource paths to
exist. If they're missing, the launched shell could end up in an
inconsistent and unexpected state.
For example, we temporarily set ZDOTDIR to our zsh shell integration
directory and then restore it from our .zshenv file, but if that script
isn't available, the user's shell environment will be broken.
The actual runtime logic change was simple: each shell integration
routine attempts to open its expected resource path and skips automatic
shell integration upon failure. The more complex change was reworking
our unit tests to run in a temporary resources directory structure.
See: #9941
