Move the search result counter inside the search text field using an
overlay, preventing layout shift when results appear.
**Before:** The counter appeared as a separate element in the HStack,
causing the text field to shift when results loaded.
**After:** The counter is overlaid inside the text field on the right
side with reserved padding, eliminating layout shift.
---
**AI Disclosure: The was entirely authored with Claude Code,
specifically with Claude Opus 4.5.**
Move the search result counter (e.g. "1/30") inside the search text
field using an overlay, preventing layout shift when results appear.
This PR was authored with Claude Code.
#189 for macOS
This adds a search GUI for macOS, including macOS-standard menu bar
items, and keybindings that match other native macOS applications such
as Terminal app, Safari, and others. This introduces a new keybinding
action `start_search` to start a blank search for GUIs.
This PR also resolves a number of minor issues found in the search
subsystem and renderer related to search from prior PRs. This should
result in overall improved search stability. **Please note there are
still known issues (bottom of this PR).**
> [!WARNING]
>
> **A note on stability:** I know a lot of people are eager to have this
feature, and I'm excited
> for this feature to soon be available in tip releases. But note that
new features like this are
> always filled with performance issues, bugs, crashes, etc. That's the
point of tip releases:
> to find and address these before wider availability. We will do our
best to respond rapidly to
> major issues found in tip, but don't expect perfect functionality
immediately!
## Demo
https://github.com/user-attachments/assets/3b81752e-d7e5-4875-9864-92497333b23e
> [!NOTE]
>
> You can drag the search window to any of the four corners if its
getting in the way of reading the terminal.
## Known Issues
TODO prior to this PR merging:
- [x] Single-byte search terms cause a crash since our sliding window
can't handle it. This PR temporarily requires search terms with length
2+ before starting a search to avoid it. 😄
- [x] The way `ScreenSearch` prunes history is fundamental unsafe. With
a rapidly growing screen that could reach history limits and an active
search at the same time, Ghostty is almost guaranteed to crash
currently. The workaround is to not search actively scrolling screens
(new data) for now.
- ScreenSearch has to restart on resize. We don't have any good way to
handle reflow since our search results are unpinned. We can look into
this later but this fixes correctness.
- PageList now tracks serial number by node that monotonically increases
on any alloc or reuse. Our screen search uses this to prune invalid
history results.
When pasting text in GTK, the current version properly prioritizes
text/plain;charset=utf-8 when the content is offered by another
application, but when pasting from ghostty to itself the mime type
selection algorithm prefers the offer order and matches `text/plain`,
which then converts non-ASCII UTF-8 into a bunch of escaped hex
characters (e.g. 日本語 becomes \E6\97\A5\E6\9C\AC\E8\AA\9E)
This is being discussed on the GTK side[1], but until everyone gets an
updated GTK it cannot hurt to offer the UTF-8 variant first (and one of
the GTK dev claims it actually is a bug not to do it, but the wayland
spec is not clear about it, so other clients could behave similarly)
Link: https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/9189 [1]
Fixes#9682
When pasting text in GTK, the current version properly prioritizes
text/plain;charset=utf-8 when the content is offered by another
application, but when pasting from ghostty to itself the mime type
selection algorithm prefers the offer order and matches `text/plain`,
which then converts non-ASCII UTF-8 into a bunch of escaped hex
characters (e.g. 日本語 becomes \E6\97\A5\E6\9C\AC\E8\AA\9E)
This is being discussed on the GTK side[1], but until everyone gets an
updated GTK it cannot hurt to offer the UTF-8 variant first (and one of
the GTK dev claims it actually is a bug not to do it, but the wayland
spec is not clear about it, so other clients could behave similarly)
Link: https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/9189 [1]
Fixes#9682
