Per review feedback, drop the `if (Discover == Windows)` comptime
branches in SharedGridSet and list_fonts by making every backend's
`init` take a Library and ignore it when unused. Call sites just do
`Discover.init(self.font_lib)` now.
Also adds a discovery test for the Windows backend that looks up
Arial and checks the returned face has the 'A' codepoint.
Co-authored-by: Claude <noreply@anthropic.com>
Resolve the system font directory from SYSTEMROOT rather than assuming
it lives on C:. If SYSTEMROOT is somehow unset we skip the system
directory instead of falling back to a literal drive letter.
Co-authored-by: Claude <noreply@anthropic.com>
Adds a FreeType-based Discover implementation for Windows that walks
the system (C:\Windows\Fonts) and per-user
(%LOCALAPPDATA%\Microsoft\Windows\Fonts) font directories, matching
descriptors via family_name / SFNT name table and optionally codepoint
presence.
Wired up as a new .freetype_windows backend which Backend.default() now
returns on Windows. Existing freetype-only paths are untouched.
With this in place, standard code paths -- +list-fonts, SharedGridSet
font-family lookup, CodepointResolver fallback -- work on Windows
without any os.tag == .windows branches in the caller.
Co-authored-by: Claude <noreply@anthropic.com>
Adds a new CI job `build-libghostty-windows-gnu` that exercises the
GNU-ABI Windows library build path. The existing
`build-libghostty-vt-windows` job covers the MSVC ABI; with the recent
fixes (#12373 / #12381 / #12382) the GNU path is now viable, and this
job catches regressions before the upcoming Win32 apprt (discussion
#2563) starts to depend on it.
Named `build-libghostty-windows-gnu` rather than following the
`build-libghostty-vt-*` convention because this job also builds
`ghostty-internal.dll`, not just libghostty-vt. Happy to rename if you
prefer a different convention.
Part of the Win32 apprt upstreaming series (see discussion #2563 /
mattn/ghostty#1).
The existing `build-libghostty-vt-windows` job builds libghostty-vt
with the MSVC ABI. The Win32 apprt (discussion #2563) will target
the GNU ABI, so add a parallel job that exercises the GNU-ABI path
to catch bitrot.
The job runs `zig build -Dtarget=native-native-gnu -Dapp-runtime=none`
which produces ghostty-vt.dll and ghostty-internal.dll without
requiring a platform-specific apprt.
Widens the existing `-fno-sanitize=undefined` gate from `abi == .msvc`
to `os.tag == .windows`. The same undefined `__ubsan_handle_*` link
errors from simdutf/highway also reproduce on Windows GNU ABI, and the
fix is identical.
Part of the Win32 apprt upstreaming series (see discussion #2563 /
mattn/ghostty#1).
`combine_archives` spawns `zig ar -M`, hard-coding the command name
`"zig"` and relying on the binary being on `PATH`. On Windows when the
build is driven by an absolute zig.exe path (common in CI and
Scoop/winget installs), this surfaces as `error: FileNotFound`.
Pass `b.graph.zig_exe` explicitly so the tool always uses the exact zig
binary driving the build, matching how other build tools in this repo
spawn zig subcommands.
Part of the Win32 apprt upstreaming series (see discussion #2563 /
mattn/ghostty#1).
`combine_archives` spawns `zig ar -M` to combine static archives via
an MRI script. It hard-coded the command name `"zig"` and relied on
the binary being on `PATH`, which fails on Windows when the build is
driven by an absolute zig.exe path (common in CI and in Scoop/winget
installs where PATH isn't populated at build time). The failure
surfaces as `error: FileNotFound` from `Child.spawn`.
Pass `b.graph.zig_exe` as the first argument so the tool always uses
the exact zig binary that is driving the build, matching how other
build tools in this repo spawn zig subcommands.
The existing `-fno-sanitize=undefined` flag was gated on `abi == .msvc`
to avoid undefined `__ubsan_handle_*` references from simdutf/highway.
The same linker error reproduces on Windows GNU ABI for the same
reason: the Zig-bundled libraries don't provide a matching UBSan
runtime for these C/C++ objects in our build configurations.
Widen the condition to `os.tag == .windows` so both MSVC and GNU
Windows targets skip ubsan for these C++ deps.
Part of preparation for adding a Win32 application runtime (discussion
#2563). One of three small, independent build fixes that together
unblock the Windows GNU-ABI library build.
On Windows with non-MSVC ABI, `pub const DllMain` resolved to `void` (a
type), and Zig's stdlib `start.zig` then tried to call it as a function
via `root.DllMain(...)`, failing to compile with "type 'type' not a
function".
This restructures the conditional so MSVC keeps its existing CRT-init
handler unchanged, non-MSVC Windows gets a no-op `BOOL` handler, and
non-Windows continues to resolve to `void`.
Verified: `zig build -Dtarget=native-native-gnu -Dapp-runtime=none
[-Doptimize=ReleaseSafe]` now builds cleanly on Windows.
Per review feedback (#12373), fold the nested `if/else if/else` into a
single Windows-gated struct whose handler picks up the abi difference
via a comptime check. This removes the duplicated `const BOOL = ...`
block that the two per-abi structs shared.
Part of preparation for upstreaming a Win32 application runtime
(see discussion #2563). This is one of three small build-related
fixes that unblock the Windows GNU-ABI library build.
When targeting Windows with GNU ABI, the existing `DllMain` declaration
falls through to `void` (a type), which Zig stdlib's `start.zig` then
attempts to call as a function via `root.DllMain(...)` - producing the
compile error "type 'type' not a function".
Restructure the conditional so that:
- non-Windows builds keep `DllMain = void`
- Windows + MSVC keeps the existing CRT-init handler (unchanged)
- Windows + non-MSVC gets a no-op `BOOL` handler
This unblocks `zig build -Dtarget=native-native-gnu -Dapp-runtime=none`
on Windows.
~`${prefix}/include` and `${prefix}/lib` are incorrect under
split-prefix installs (e.g. Nix multi-output). Use `b.h_dir` /
`b.lib_dir` instead and drop the unneeded Nix postInstall/postFixup
hooks.~
Refactors the libghostty-vt derivation to:
- fix `libdir` pointing to the wrong output in the pkg-config files.
This would throw a missing library error at runtime.
- reduce the amount of manual copying, linking, and patching of files.
An earlier version of this PR used the zig compiler + `.pc` files to do
this. People pointed out concerns, so I came up with a simpler solution.
Claude Code was used to debug and write an initial fix. Final changes
rewritten and simplified by me. No AI was used to write comments,
descriptions, etc.
`${prefix}/include` and `${prefix}/lib` are wrong under split-prefix installs (e.g. Nix multi-output).
Use `b.h_dir` / `b.lib_dir` instead and drop the unneeded Nix postInstall/postFixup hooks.
Co-Authored-By: Sander <hey@sandydoo.me>
This helps developers like me to use a separate config for debugging
(which is already supported by the environment variable
`GHOSTTY_CONFIG_PATH`).
I can already use the local scheme to load a debugging config file, but
when opening the config file through Ghostty, it will still open the
default config.
This changes doesn't affect the release build, since `configPath` is
only set in the DEBUG build.
The GhosttyKit xcframework previously shipped the entire include/
directory, which pulled in the libghostty-vt headers under
include/ghostty/. Because those headers are not referenced from the
ghostty.h umbrella, Clang's module system emitted "umbrella header for
module 'GhosttyKit' does not include header 'ghostty/vt/*.h'" warnings
in Xcode builds.
Stage only ghostty.h and module.modulemap via addWriteFiles so the
xcframework Headers directory contains exactly the GhosttyKit API,
mirroring the pattern used in GhosttyLibVt.xcframework.
## AI disclosure
Claude made the changes (including the commit message), I reviewed and
tested them.
The GhosttyKit xcframework previously shipped the entire include/
directory, which pulled in the libghostty-vt headers under
include/ghostty/. Because those headers are not referenced from the
ghostty.h umbrella, Clang's module system emitted "umbrella header for
module 'GhosttyKit' does not include header 'ghostty/vt/*.h'" warnings
in Xcode builds.
Stage only ghostty.h and module.modulemap via addWriteFiles so the
xcframework Headers directory contains exactly the GhosttyKit API,
mirroring the pattern used in GhosttyLibVt.xcframework.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Looks like `NSWorkspace.shared.setIcon` can only be called from the main
App, DockTilePlugin is sandboxed and doesn't have the permission to
`file-write-finderinfo`.
<img width="1186" height="144" alt="image"
src="https://github.com/user-attachments/assets/e5ea4f1c-718c-493a-bda2-32787881881e"
/>
It works fine in debug, but not in release. This fixes#11489
* Fix a memory leak when invalid Kitty graphics data is sent via APC
(this is the only commit for backporting to 1.3.2)
* Add `max_bytes` to limit size of buffered APC data by protocol to
prevent DoS, default to reasonable values
* libghostty: expose max bytes APC options
Expose the foreground process PID and TTY device path as read-only properties on the AppleScript terminal class and App Intents TerminalEntity. This enables reliable process-to-terminal mapping for automation tools when multiple terminals share the same CWD.
Closes#11592Closes#10756
Session: 019d341c-a165-7843-a2f7-2f426114cf17
Looks like `NSWorkspace.shared.setIcon` can only be called from the main App, DockTilePlugin is sandboxed and doesn't have the permission to `file-write-finderinfo`.
It works fine in debug, but not in release. This fixes#11489, #11290
Stop trying to use POSIX shared memory functions such as `shm_open` on
Android as it's unsupported and the platform libc does not have those
symbols.
This avoids an error such as the below when trying to use
`libghostty-vt` on Android:
> dlopen failed: cannot locate symbol "shm_open" referenced by [..]
Stop trying to use POSIX shared memory functions such as
`shm_open` on Android as it's unsupported and the platform libc does not
have those symbols.
This avoids an error such as the below when trying to use
`libghostty-vt` on Android:
> dlopen failed: cannot locate symbol "shm_open" referenced by [..]
