https://github.com/rcaloras/bash-preexec/releases/tag/0.7.0
We only source bash-preexec for bash < 4.4, so most of this release is
inert for us: the PS0 function-substitution hook (bash >= 5.3) and the
array PROMPT_COMMAND handling (bash >= 5.1) are never reached. What we
do pick up is the simpler install string, per-prompt re-adjustment of
PROMPT_COMMAND when something else modifies it, preservation of $? and
$_ on early returns, and the first-command preexec fix.
We continue to carry one local modification: __bp_adjust_histcontrol
stays disabled in the DEBUG trap hook so the user's HISTCONTROL is
respected (#2269). The original justification was that we didn't use
the preexec command argument, which is no longer true because we use it
for the window title. The comment now explains the current reasoning:
our bash >= 4.4 integration also uses `history 1` without adjusting
HISTCONTROL and accepts the same inaccuracy for space-prefixed commands,
so the legacy path is kept consistent with it.
## 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.
