Scrollback search highlight is overridden by text selection

[injust]

Issue Description

The highlighting of matches in scrollback search is lower priority than that of text selection.

This is notably confusing if you select a word in the terminal, then copy and paste it into scrollback search (e.g. to find other occurrences). It looks like there is 1 fewer match than actual.

Expected Behavior

Highlighting of matches (whether active or inactive) by scrollback search should be higher priority than highlighting of selected text.

Actual Behavior

The 3rd match is the "oc" in "Documents", but you can't see it because I selected the text.

Reproduction Steps

1. Select any text
2. Open scrollback search and type some substring of the selection

Ghostty Logs

No response

Ghostty Version

Ghostty 1.3.0-main+2d9dc5cfd

Version
  - version: 1.3.0-main+2d9dc5cfd
  - channel: tip
Build Config
  - Zig version   : 0.15.2
  - build mode    : .ReleaseFast
  - app runtime   : .none
  - font engine   : .coretext
  - renderer      : renderer.generic.Renderer(renderer.Metal)
  - libxev        : kqueue

OS Version Information

macOS Sequoia 15.7.4

Minimal Ghostty Configuration

# empty

Additional Relevant Configuration

No response

I acknowledge that:

• I have reviewed the FAQ and confirm that my issue is NOT among them.
• I have searched the Ghostty repository (both open and closed Discussions and Issues) and confirm this is not a duplicate of an existing issue or discussion.
• I have checked the "Preview" tab on all text fields to ensure that everything looks right, and have wrapped all configuration and code in code blocks with a group of three backticks (```) on separate lines.

[mitchellh]

There is another discussion you can find where this was done on purpose, otherwise it makes selecting a highlight to copy very difficult because you can't actually see the selection. iTerm2 works similarly. Terminal.app just stops highlighting the search match when you start highlighting which I think is just the worst of all lol.

[injust]

That makes sense. I didn't initially see it that way because my flow is always selecting text -> pasting it into scrollback search, not the other way around.

[rhodes-b]

That makes sense. I didn't initially see it that way because my flow is always selecting text -> pasting it into scrollback search, not the other way around.

there is a specific action for that fyi so you dont need to manually copy and paste search_selection not sure if its hooked up to any keybind by default but you can easily test with the command palette

[injust]

there is a specific action for that fyi so you dont need to manually copy and paste search_selection not sure if its hooked up to any keybind by default but you can easily test with the command palette

Sweet, you can use this:

keybind = cmd+f=search_selection
keybind = chain=start_search

to populate scrollback search with the selected text, but still open scrollback search if nothing is selected.