## Summary
- Adds Serbian translations for both Cyrillic (`sr`) and Latin
(`sr@latin`) scripts, registered in `src/os/i18n_locales.zig` and
`CODEOWNERS`.
- `po/sr@latin.po` is generated from `po/sr.po` with `msgfilter
recode-sr-latin` and should not be translated by hand.
- Replaces the closed#13030; strings are rebased onto current `main`.
Cc @slowdub for a review.
EDIT: AI disclosure: I used Cursor (Grok 4.6) for mechanical repo work
only, not for writing the Serbian translations. The agent fetched
ghostty-org/ghostty, branched from current main, ran msgmerge on
po/sr.po against the template, generated po/sr@latin.po with msgfilter
recode-sr-latin, registered sr / sr@latin in src/os/i18n_locales.zig and
CODEOWNERS, rebased my three commits onto later main, pushed the branch,
and opened this PR (I had intended to open the PR myself, s***** thing
ignored my instructions). I translated and reviewed sr.po and the Latin
file is a recode of that catalog, not a separate translation since
Serbian Cyrillic can be perfectly transcoded to the Latin script via
[recode-sr-latin](https://linux.die.net/man/1/recode-sr-latin).
This exposes the terminal search API through libghostty C and Zig APIs.
This was previously available through the Zig APIs but forced our
threading model. I've now extracted the full terminal search state to a
new `terminal.search.TerminalSearch` structure so threading isn't
forced. The C API is completely new.
## Example (C)
```c
GhosttySearch search;
ghostty_search_new(NULL, &search, terminal);
GhosttyString needle = { (const uint8_t *)"error", 5 };
ghostty_search_set(search, GHOSTTY_SEARCH_OPT_NEEDLE, &needle);
ghostty_search_run(search);
// Find bar chrome: "k of n"
size_t total, idx;
ghostty_search_get(search, GHOSTTY_SEARCH_DATA_TOTAL_MATCHES, &total);
// Enter: select the next match (wraps, scrolls the viewport if needed)
ghostty_search_set(search, GHOSTTY_SEARCH_OPT_SELECT_NEXT, NULL);
ghostty_search_get(search, GHOSTTY_SEARCH_DATA_SELECTED_INDEX, &idx);
ghostty_search_free(search);
```
Reported in https://github.com/ghostty-org/ghostty/discussions/14064
I validated this myself manually. The zero-ref branch of
`addWithIdContext` incremented `living` unconditionally even if `upsert`
resolved the value to an item that was already alive under a different
ID.
This would cause `living` to be invalid for each time this happened and
the downstream effect was that `count()` drifted. I couldn't find any
crashing or invalid effect except that this caused requested style
memory to be over-provisioned.
cc @qwerasd205 since its ref counted set, but I did this work manually
❤️
For middle-click-action
* Kept the option "primary-paste" instead of "paste-primary" to keep
backwards compatibility
* Added the option "clipboard-paste"
For copy-on-select
* Added the both, none and primary options
Updated config documentation
Note: No AI was used, Even though I don't know Zig, I looked at the code
and the modifications seemed easy enough
Closes#12600
Before this change, ghostty frequently logs the following warning, even
though a `gtk-xft-dpi` value of `-1` is valid and indicates default
scaling.
```
warning(gtk_ghostty_surface): gtk-xft-dpi has invalid value (-1), using default
```
From [the gtk
docs](https://docs.gtk.org/gtk4/property.Settings.gtk-xft-dpi.html):
> The font resolution, in 1024 * dots/inch.
>
> -1 to use the default value.
Before this change, ghostty frequently logs the following warning, even though a `gtk-xft-dpi` value of `-1` is valid and indicates default scaling.
```
warning(gtk_ghostty_surface): gtk-xft-dpi has invalid value (-1), using default
```
From [the gtk docs](https://docs.gtk.org/gtk4/property.Settings.gtk-xft-dpi.html):
> The font resolution, in 1024 * dots/inch.
>
> -1 to use the default value.
A follow on for #14035, we can now fix a long standing
effiency/performance bug now that we park the display link while idle.
This actually could cause "animated" un-focused windows to use more GPU
than their focused counterparts. (AI Agent interfaces seem to love
animation).
6ae1784f4
Unfocused surfaces stopped the CVDisplayLink and encoded a GPU frame on
every PTY wakeup. A burst of close writes became that many Metal submits
instead of one vsync.
Keep the link running while the surface is visible and dirty or
animating, whether or not it is focused. Idle surfaces still park.
Reported in https://github.com/ghostty-org/ghostty/discussions/14064
I validated this myself manually. The zero-ref branch of `addWithIdContext`
incremented `living` unconditionally even if `upsert` resolved the value
to an item that was already alive under a different ID.
This would cause `living` to be invalid for each time this happened and
the downstream effect was that `count()` drifted. I couldn't find any
crashing or invalid effect except that this caused requested style memory
to be over-provisioned.
Update the macOS Sparkle dependency from 2.9.0 to 2.9.4.
This keeps the Swift package resolution and all tag/tip release workflow
downloads aligned on the same version. Sparkle 2.9.2 included fixes for
GHSA-g3hp-f6mg-559v and GHSA-hg88-v3cw-3qrh; 2.9.4 is the current stable
release.
Validation:
- verified the 2.9.4 release contains
`Sparkle-for-Swift-Package-Manager.zip`
- verified the lockfile revision matches the 2.9.4 tag
- `jq empty` on `Package.resolved`
- `git diff --check`
I could not run Xcode package resolution locally because the active
developer directory is Command Line Tools rather than a full Xcode
installation.
Native freestanding targets cannot emit shared libraries and do not provide an OS page size, stack unwinder, hosted SIMD dependencies, or filesystem-backed Kitty graphics. Build only the static artifact for those targets, define the minimum alignment used for terminal pages, disable hosted-only defaults, and install the public headers with the archive.
