The default Zig panic handler unwinds the stack and symbolicates it,
which drags in ~160KB worth of helper machinery. For an embedded library
this isn't great because the embedder's environment should be providing
this as long as libghostty is compiled with symbols or has a way to
symbolize.
Change ReleaseFast/ReleaseSmall libghostty-vt builds to use a custom
panic handler. Debug/ReleaseSafe keep the full Zig handlers.
This shrinks libghostty-vt on macOS by ~160KB (~9%).
This PR adds a `+new-tab` CLI action, useful for automation on GTK. This
mainly re-uses machinery added for the `+new-window`, but adds in a
unique surface ID for identifying surfaces for IPC purposes (and
eliminates use of raw pointers for callbacks from notifications).
Use the standard `~/Android/Sdk` capitalization for the Linux SDK
fallback.
This lets NDK discovery work when neither `ANDROID_NDK_HOME` nor an
`SDK` environment variable is set.
Fixes hundreds of complaints about the fact that drag handles cannot be
hidden, on GTK at least.
I'm not sure if we ever made an issue for this? If you come across any
discussions asking for this, please link them here :)
It turns out we never unbound the split from its original tree after
moving, which means `is-split` in particular is desynced and leads to
hilarious artifacts like how `unfocused-split-*` options just stop
working properly. I only realized this is a thing after the naïve
drag handle config option didn't work properly. Fun!
Use the standard ~/Android/Sdk capitalization for the Linux SDK fallback.
This lets NDK discovery work when neither ANDROID_NDK_HOME nor an SDK
environment variable is set.
Signed-off-by: Fredrik Fornwall <fredrik@fornwall.net>
Ghostty's full termio path answers XTGETTCAP from the static terminfo
map, but `terminal/stream_terminal.zig`, which backs libghostty-vt,
parses the same DCS request and then discards it. There is no XTGETTCAP
effect either, so an embedder cannot restore the replies through the C
API.
Programs query these over SSH instead of assuming the remote host has
the client's terminfo entry. This matters more for an embedder than for
the desktop app, which can install its entry on the remote through shell
integration.
Answer the queries in `stream_terminal` the same way termio does: look
up each requested key in the static terminfo map and write the reply to
the pty, skipping the lookups entirely when no `write_pty` effect is
set. The map now stores null-terminated responses so they can be handed
straight to `write_pty` without copying. `terminal/dcs.zig` and the
termio path are unchanged.
`TN` is handled separately. It names the terminfo entry the terminal
runs as, so it has to agree with `TERM` — which is set in
`termio/Exec.zig`, a layer libghostty-vt does not contain. The library
never sees `TERM` and cannot answer on the embedder's behalf, and
answering with Ghostty's own entry from the static map would misreport
every embedder, so `TN` is intercepted before the map lookup. The name
is instead configured through a new option,
`GHOSTTY_TERMINAL_OPT_TERMINFO_NAME`: the string is copied into the
terminal, names longer than 128 bytes are rejected, and while unset the
query goes unanswered.
This is the first dependency from `src/terminal` on `src/terminfo`, so
libghostty-vt now carries Ghostty's terminfo table: +16,023 bytes
(+1.9%) on a `wasm32-freestanding` `ReleaseSmall` build.
---
AI usage: Created with claude code and opus 5. I have reviewed the code
and made modifications where it made sense. I have also tested this end
to end in an application.
Ghostty's full termio path answers XTGETTCAP from the static terminfo
map, but terminal/stream_terminal.zig, which backs libghostty-vt,
parses the same DCS request and then discards it. There is no XTGETTCAP
effect either, so an embedder cannot restore the replies through the
C API.
Programs query these over SSH instead of assuming the remote host has
the client's terminfo entry. This matters more for an embedder than for
the desktop app, which can install its entry on the remote through
shell integration.
Answer the queries in stream_terminal the same way termio does: look
up each requested key in the static terminfo map and write the reply
to the pty, skipping the lookups entirely when no write_pty effect is
set. The map now stores null-terminated responses so they can be
handed straight to write_pty without copying. terminal/dcs.zig and the
termio path are unchanged.
"TN" is handled separately. It names the terminfo entry the terminal
runs as, so it has to agree with TERM -- which is set in
termio/Exec.zig, a layer libghostty-vt does not contain. The library
never sees TERM and cannot answer on the embedder's behalf, and
answering with Ghostty's own entry from the static map would misreport
every embedder, so "TN" is intercepted before the map lookup. The name
is instead configured through a new option,
GHOSTTY_TERMINAL_OPT_TERMINFO_NAME: the string is copied into the
terminal, names longer than 128 bytes are rejected, and while unset
the query goes unanswered.
This is the first dependency from src/terminal on src/terminfo, so
libghostty-vt now carries Ghostty's terminfo table: +16,023 bytes
(+1.9%) on a wasm32-freestanding ReleaseSmall build.
Signed-off-by: Fredrik Fornwall <fredrik@fornwall.net>
This introduces a new effect for Zig/C callers to detect unknown
sequences.
This PR starts only with APC, but the API shape is such that we can add
other types (OSC next) in future PRs. The goal of this is to have zero
overhead in the disabled/undetected (both) case, and minimal overhead in
the detected case.
This is important in particular for libghostty consumers because it
allows them to implement their own custom protocols and/or support
features libghostty doesn't support. It isn't possible to support them
at the same performance libghostty does but supporting them in general
is usually valuable.
From a Zig API to enable this, users must set `unknown_max_bytes` for
the APC handler AND update their stream handler to recognize unknown
sequences. The built-in `stream_terminal` stream type has an exposed
callback for this, so both must be set.
Fix two resource leaks when the Wayland background blur region changes.
Temporary `wl_region` objects were destroyed only after an error. They
are now always destroyed after the blur request. The previous cached
blur region is also released before its replacement.
This change does not alter protocol selection or add new Wayland
protocols.
Testing:
- Verified blur on KDE Plasma 6.7.4 with GTK 4.22.4.
- Verified with `zig build -Doptimize=ReleaseFast`.
This code was written with assistance from GPT 5.6 Sol and manually
reviewed.
Destroy temporary Wayland regions after each blur update and release
the previous cached blur region before replacing it. This prevents
resources from leaking while the blur region changes.
APC payload bytes are bulk consumed, but the terminating byte still passed
through the generic parser action loop. Handle ESC and C1 ST directly after
bulk consumption while leaving other transitions on the scalar path.
For new windows to get their appearance synced, we need to call
`syncAppearance` after `super.showWindow(sender)`. All previous calls to
`syncAppearance` on `TerminalWindow` will be ignored because the window
needs to have `isVisible` set to `true`.
This regression was introduced by:
5368adcd29
It added `.dropFirst()` to the `focusedSurface` appearance publishers in
`TerminalController.swift` which removes the initial call of the
subscription.
Fixes https://github.com/ghostty-org/ghostty/issues/13324
(landed on the same fix as @rasitakyol found here:
https://github.com/ghostty-org/ghostty/pull/13341)
Remove BLAKE3 prefix digests. Keep READY/FINISH as empty records since
they're semantically important markers.
Our existing format (CRC32 per-record, declared counts, strict tag
ordering requirements, etc.) already detect: accidental corruption,
truncation, data omission, and duplication.
BLAKE3 only protects against valid records being swapped or removed
entirely. It is heavy for just that, and callers can solve that anyways
via their own transport (like, just use TCP). For more adversarial
protection, callers can also add layers like TLS or their own alternate
signing methods depending on their own threat models.
Removing the hash improves encode times by ~1.4x, decode times by ~1.3x.
Time-to-READY decoding is effectively unchanged because it was such a
small package to begin with.
**AI usage:** I had it clean up the comments and the tests, but I did
the blake3 removal and marker changes, and wrote the commit message
myself. All reviewed.
This fixes regressions in the flatpak/snap builds, and knock-on stuff
that was discovered as as a result:
* Update the Zig versions in the flatpak/snap build configuration files.
* Restore the classic `-Dpatch-rpath` option, and add a new
`-Dpatch-interp` option. This ensures that the snap can still use
`-Dpatch-rpath` correctly.
* There seems to be an issue in Zig when parsing IPv6 addresses that
leads to issues loading `resolv.conf` files; when trying to load a
nameserver that has an IPv6 address with a numeric interface index as
the scoped zone ID, Zig will try to resolve the interface as a name
rather than just use the index. This is coming up in snap builds because
the build process seems to, by default, use the exhaustive
`/run/systemd/resolve/resolv.conf` file, versus the simpler stub
(`stub-resolv.conf`) file. We work around this for the time being by
linking the stub at the end of the Zig part, overwriting the link to the
non-stub file.
* Fixed `gtk4-layer-shell` packaging - the migration to external
translate-c meant that non-system builds of the dependency were not
handing the local `gtk4-layer-shell` headers over for translation. Now,
instead, we've extracted the management of the `gtk4-layer-shell` source
and `wayland-protocols` generation to a locally-cached object so that
the source can be shared by both C translation and the library build in
a way that is not coupled to any particular step.
Catch NULL results from CoreFoundation/CoreText creation functions and
return error.OOM rather than null derefs later. I verified that this is
possible but didn't verify the behavior when it happens, this is just
defensive based on the report here: #13671 because it costs us nothing
really.
Discard the selection notification payload before debouncing
accessibility changes.
The debouncer previously retained the notification and its surface
object, keeping a closed tab's view and PTY alive after the undo
timeout.
I was messing around with this tool the other day on a 60% keyboard so I
thought this would be a nice addition for situations like that. Keeps in
line with the vi/less j and k inputs that this tool has as well.
Remove BLAKE3 prefix digests. Keep READY/FINISH as empty records since
they're semantically important markers.
Our existing format (CRC32 per-record, declared counts, strict tag ordering
requirements, etc.) already detect: accidental corruption, truncation,
data omission, and duplication.
BLAKE3 only protects against valid records being swapped or removed entirely.
It is heavy for just that, and callers can solve that anyways via their
own transport (like, just use TCP). For more adversarial protection,
callers can also add layers like TLS or their own alternate signing
methods depending on their own threat models.
Removing the hash improves encode times by ~1.4x, decode times by ~1.3x.
Time-to-READY decoding is effectively unchanged because it was such a
small package to begin with.
Catch NULL results from CoreFoundation/CoreText creation functions and
return error.OOM rather than null derefs later. I verified that this is
possible but didn't verify the behavior when it happens, this is just
defensive based on the report here: #13671 because it costs us nothing
really.
This fixes regressions in the flatpak/snap builds, and knock-on stuff
that was discovered as as a result:
* Update the Zig versions in the flatpak/snap build configuration files.
* Restore the classic -Dpatch-rpath option, and add a new -Dpatch-interp
option. This ensures that the snap can still use -Dpatch-rpath
correctly.
* There seems to be an issue in Zig when parsing IPv6 addresses that
leads to issues loading resolv.conf files; when trying to load a
nameserver that has an IPv6 address with a numeric interface index as
the scoped zone ID, Zig will try to resolve the interface as a name
rather than just use the index. This is coming up in snap builds
because the build process seems to, by default, use the exhaustive
/run/systemd/resolve/resolv.conf file, versus the simpler stub
(stub-resolv.conf) file. We work around this for the time being by
linking the stub at the end of the Zig part, overwriting the link to
the non-stub file.
* Fixed gtk4-layer-shell packaging - the migration to external
translate-c meant that non-system builds of the dependency were not
handing the local gtk4-layer-shell headers over for translation. Now,
instead, we've extracted the management of the gtk4-layer-shell source
and wayland-protocols generation to a locally-cached object so that
the source can be shared by both C translation and the library build
in a way that is not coupled to any particular step.
Discard the selection notification payload before debouncing
accessibility changes.
The debouncer previously retained the notification and its surface
object, keeping a closed tab's view and PTY alive after the undo
timeout.
There're won't be any visible errors, but
`keybind=cmd+r=toggle_tab_overview/toggle_window_decorations/size_limit/quit_time`
shouldn't go to `showChildExited`
## AI Disclosure
Found by Claude during another quest, but I changed on myself.
