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).
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!
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.
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.
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.
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.
ABI BREAKING: This removes `ghostty_terminal_mode_get` and `_mode_set`.
We can now represent these operations completely with standard
`ghostty_terminal_get` and `ghostty_terminal_set`, which makes it much
more flexible to preserve ABI in the future.
This is all centered around a new `GhosttyTerminalModeConfig` structure
that is an in or out parameter depending on use case.
This also adds a new `GHOSTTY_TERMINAL_OPT_MODE_DEFAULT` option that can
be used to set the _default_ value of mode that happens when a RIS event
(full reset) is sent. Note that not all modes are configurable because
some are set based on live terminal state and aren't modes in and of
themselves.
## Why Delete Functions? Why Not Add?
Once tagged, the goal of `libghostty-vt` is to remain HIGHLY ABI
compatible. We are striving for top tier ABI compatibility similar to
legendary C libraries. That means we need to be highly confident in our
API shapes: functions, structs, etc. and using shapes that we can retain
ABI compatibility even as we add features. Every function is a risk. By
pushing stuff into our `_get/_set` patterns, its easier to maintain ABI
compatibility.
Related to #10651
Default Ghostty dependency builds to libghostty-vt-only mode and avoid
initializing anything that would trigger broader dependency
requirements.
The impact of this is that Zig consumers can import ghostty-vt without
requiring Xcode on macOS.
ABI BREAKING: This removes `ghostty_terminal_mode_get` and `_mode_set`.
We can now represent these operations completely with standard
`ghostty_terminal_get` and `ghostty_terminal_set`, which makes it much
more flexible to preserve ABI in the future.
This is all centered around a new `GhosttyTerminalModeConfig` structure
that is an in or out parameter depending on use case.
This also adds a new `GHOSTTY_TERMINAL_OPT_MODE_DEFAULT` option that
can be used to set the _default_ value of mode that happens when a RIS
event (full reset) is sent.
Related to #10651
Default Ghostty dependency builds to libghostty-vt-only mode and
avoid initializing anything that would trigger broader dependency
requirements.
The impact of this is that Zig consumers can import ghostty-vt without
requiring Xcode on macOS.
The purpose of SegmentedPool was pointer-stable values for the pty write
path, and the std.MemoryPool provides that.
SegmentedPool is actually so old it predates a stdlib memory pool! Just
noting why I did it in the first place. I also wrote it when I was
pretty fucking bad at Zig, so I'm shocked its lasted this long.
The write path is hot , so the replacement was benchmarked against the
old SegmentedPool plus a rewrite simple Pool I did before realizing...
wait... why not just a MemoryPool. Benchmarked using the real 240-byte
xev write request.
```
workload old std.MemoryPool
depth-1 (keystroke echo) 3.93 ns/op 0.96 ns/op
burst (1MiB paste, d=256) 4.27 ns/op 1.00 ns/op
cold growth (32 -> 16k) 4.54 ns/op 6.48 ns/op
malloc create/destroy 15.9 ns/op (baseline)
```
Cold growth is slower but this is only a cost when the pool grows.
Note this also gets rid of the preallocation, which didn't show any
measurable performance benefit at all. This has the benefit of shrinking
our ThreadData by ~10KB.
This was motivated by #13655
The purpose of SegmentedPool was pointer-stable values for the pty write
path, and the std.MemoryPool provides that.
SegmentedPool is actually so old it predates a stdlib memory pool!
Just noting why I did it in the first place. I also wrote it when I was
pretty fucking bad at Zig, so I'm shocked its lasted this long.
The write path is hot , so the replacement was benchmarked against the old
SegmentedPool plus a rewrite simple Pool I did before realizing...
wait... why not just a MemoryPool. Benchmarked using the real 240-byte xev
write request.
workload old std.MemoryPool
depth-1 (keystroke echo) 3.93 ns/op 0.96 ns/op
burst (1MiB paste, d=256) 4.27 ns/op 1.00 ns/op
cold growth (32 -> 16k) 4.54 ns/op 6.48 ns/op
malloc create/destroy 15.9 ns/op (baseline)
Cold growth is slower but this is only a cost when the pool grows.
Note this also gets rid of the preallocation, which didn't show any
measurable performance benefit at all. This has the benefit of shrinking
our ThreadData by ~10KB.
This fixes#13647 by using at most one GStreamer thread per application.
This was previously addressed in #12815 which used at most one GStreamer
thread per surface. Originally discussed in #12808.
Image eviction removed associated placements from storage without
deinitializing them. Pin-backed placements therefore remained registered
with the screen after eviction, allowing graphics-heavy output to
accumulate stale tracked pins.
Pass the owning screen through image insertion and eviction, and
deinitialize each placement before removing it. Cover both the released
pin and a retained image's live pin in the eviction regression test.
Surface.handleMessage allocated a null-terminated copy for every working
directory update. OSC 7 values fit within the parser's 2 KiB fixed
buffer, so use stack-fallback storage sized for that bound and its
terminator.
The message type does not enforce the OSC bound, so an oversized future
producer still falls back to the heap. performAction already borrows the
value only for the duration of the call, preserving its existing
lifetime.
Image eviction removed associated placements from storage without
deinitializing them. Pin-backed placements therefore remained registered
with the screen after eviction, allowing graphics-heavy output to
accumulate stale tracked pins.
Pass the owning screen through image insertion and eviction, and
deinitialize each placement before removing it. Cover both the released
pin and a retained image's live pin in the eviction regression test.
Co-authored-by: Tim Culverhouse <tfc@ampcode.com>
Surface.handleMessage allocated a null-terminated copy for every working
directory update.
Use a small 256-byte stack-fallback buffer for common working directory
lengths without adding significant pressure to this deep call stack. Longer
paths retain the existing heap behavior, and performAction continues to borrow
the value only for the duration of the call.
Track each image's placement count in its existing metadata. This lets
us use constant-time usage checks (rather than scans) during eviction.
Select the best candidate directly from storage on each eviction,
preserving the existing priority order: unused status, transient hint,
generation, then ID.
Since eviction no longer allocates, it can't fail, so callers no longer
need to handle out-of-memory conditions.
Fix d=p and d=c point deletion so only placements intersecting the
target cell are removed.
Previously, placements spanning multiple rows could be deleted from
columns outside the target because the page-order comparison flattened
row and column coordinates.
Check the rectangle's column independently and use page order only for
its row span, matching Kitty's implementation:
https://github.com/kovidgoyal/kitty/blob/master/kitty/graphics.c
NOTE: I did not look at Kitty's source prior to fixing this. I only
referenced it after the fix to verify that the behavior matches.
Spec:
https://sw.kovidgoyal.net/kitty/graphics-protocol/#deleting-images
Debug libghostty-vt dependencies embedded in ReleaseFast or ReleaseSmall
binaries no longer panic when narrow text overwrites the tail of a wide
glyph.
Replace the root module's std.debug.runtime_safety gate with
build_options.slow_runtime_safety so mixed optimization modes use the
dependency's safety configuration consistently.
#12755
Reset previously copied the active default into the override. This is
wrong, a reset should unset the override and defer back to the default.
Reset foreground, background, and cursor colors now resolve through the
current default while explicit OSC overrides remain unchanged across
configuration updates.
Set a configured background in the OSC 11 regression, assert OSC 111
clears its override, then change the default to verify the reset color
follows it.
#12885
Ghostty already implements SGR 53 and 55, but its terminfo description
does not expose the corresponding Smol and Rmol capabilities. Add both
entries so the advertised capabilities match the renderer. Tmux uses
this to gate overline.
Fixes#13219
Screen file actions intentionally retain their temporary directory so
the generated path remains valid after dispatch. The directory and
parent handles were retained with it, while TempDir.deinit also left the
parent handle open.
Each successful action leaked two descriptors. Repeated screen,
scrollback, or selection writes could exhaust the process descriptor
limit and prevent new PTYs, tabs, and windows from opening.
Give TempDir an exhaustive close mode that either deletes or retains its
contents while always releasing both handles. Defer screen-file cleanup,
retaining only after successful dispatch, and cover both lifecycle paths
with descriptor tests.
Fixes#13269
Move VT tabstop serialization ahead of screen formatting so
cursor-moving CHA and HTS sequences run before screen state is restored.
Tabstop-enabled snapshots previously finished at the final configured
tabstop instead of the serialized cursor position. Replaying a snapshot
could resume input in the wrong column.
Keep tabstop bytes in their original pin-map accounting and extend the
round-trip test to verify tabstops, cursor position, and map length.
Fixes#13293
Treat Core Video display link creation as optional when macOS has no
active displays. The previous error path reported every creation failure
as out of memory and aborted renderer initialization.
Tabs created while the session is locked now initialize normally and
fall back to event-driven rendering without vsync.
Fixes https://github.com/ghostty-org/ghostty/discussions/13242
Clear the IOSurfaceLayer display callback when releasing the wrapper.
The host view can retain the backing layer beyond renderer teardown.
This prevents a later Core Animation display pass from invoking the
callback with a freed renderer context.
This doesn't happen the way Ghostty GUI uses our renderer, but it is
possible for folks using ghostty-internal and its straightforward and
easy for us to fix it.
Debug libghostty-vt dependencies embedded in ReleaseFast or ReleaseSmall
binaries no longer panic when narrow text overwrites the tail of a wide
glyph.
Replace the root module's std.debug.runtime_safety gate with
build_options.slow_runtime_safety so mixed optimization modes use the
dependency's safety configuration consistently.
#12755
Reset previously copied the active default into the override. This is
wrong, a reset should unset the override and defer back to the default.
Reset foreground, background, and cursor colors now resolve through the
current default while explicit OSC overrides remain unchanged across
configuration updates.
Set a configured background in the OSC 11 regression, assert OSC 111
clears its override, then change the default to verify the reset color
follows it.
