macOS search: unexpected behaviors

[joeshaw]

Issue Description

These aren't necessarily bugs, but they're some unexpected things I've encountered while using the macOS search feature in tip. In most cases these are just ways that Ghostty differs from other native terminals or other Mac software. I think a discussion is more appropriate than filing issues because (a) there are a few things here and may be related or not implementation-wise and (b) they're mostly opinions rather than objective bugs.

For keybinding things, this is my current keybinding setup for search. I think it's the default:

keybind = super+g=navigate_search:next
keybind = super+shift+f=end_search
keybind = super+shift+g=navigate_search:previous
keybind = escape=end_search
keybind = super+f=start_search

Use of keybindings in focused search bar

I typically cmd-f to start a search, type in the search term, then hit cmd-g/cmd-shift-g to scroll through subsequent matches. This works if the terminal is focused, but not if the search bar is focused. I think it should work in both cases. This is how iTerm2, Safari, Chrome, etc. work.

Likewise, hitting cmd-f again when the search bar is focused should select all the text so typing will start a new search from scratch.

I like that enter works in the search bar.

Escape should dismiss the search bar

Another consistency thing with Mac apps, rather than esc returning focus to the terminal, I think it should dismiss the search bar and remove highlighted search terms.

The search bar should remember what was previously entered when it is recreated

Related to dismissing the search bar, Mac apps remember what the previous value was in the search bar when cmd-f is hit again. This also reruns the search and causes the matches to be highlighted again. The text is selected, though, so typing in new text immediately replaces the old text. Again, how iTerm2, Safari, and other apps work.

Search wrap around

Hitting cmd-g or shift-cmd-g should wrap the search around to the end or start of the buffer when there are no more matches. Another consistency thing.

Search highlights don't work on selected text

This one is a bug I just ran into. As I navigate back through matches, if they enter into a selection area I lose the highlighting.

In this screen shot, the "search" in the "keybind = super+f=start_search" should be highlighted, but you can't tell because of the selection. So I guess the search match color should be a higher priority than the mouse selection color.

Search bar covers up matches

A nice to have. I like the floating search bar, but if you are unlucky, the search bar can completely occlude a search result and you'd never know it. Here's an example as I search for "palette". The currently-highlighted match is completely behind the bar.

I understand that I can drag the bar around, but it would be nice if the viewport scrolled so that it didn't appear behind the search bar. I guess this might be tricky if the bar is at the bottom, but it's at least doable if it's at the top.

Expected Behavior

I expect Ghostty to behave more like a native Mac app with regard to search behavior.

Actual Behavior

See above.

Reproduction Steps

Mostly mentioned above.

Ghostty Logs

No response

Ghostty Version

Ghostty 1.3.0-main+34fd1dd0f

Version
  - version: 1.3.0-main+34fd1dd0f
  - 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 26.1 (Tahoe)

(Linux only) Display Server

None

(Linux only) Desktop Environment/Window Manager

No response

Minimal Ghostty Configuration

Default config

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.

[joeshaw]

Escape should dismiss the search bar

I am now waffling on this one. I'm starting to appreciate the behavior of shifting the focus back to the terminal without dismissing the search results.

[danielwe]

and when you actually want to dismiss the search, just hit Esc twice

[chaychoong]

the behavior of shifting the focus back to the terminal without dismissing the search results

dismiss the search, just hit Esc twice

I guess the main issue is that the discoverability of these behaviours - intentional or not - isn't immediately obvious, especially when there is a X button in the search bar, which behaves the same way (hitting it once brings the focus to the terminal, and then again to close it), but the affordance of that symbol suggests that it should dismiss the bar.

Not to mention, this behaviour isn't consistent too. When you interact with the search bar, like going to the next/previous result first - which brings the focus onto the terminal - then hitting escape just once will dismiss the search bar.

[ksweetie]

FWIW, pressing escape once to dismiss search is the behavior I expect from an app on MacOS. I've tried all the other apps I use, and they all close search on a single escape. VSCode is interesting in that it closes the GUI element on the first escape, but leaves all occurrences highlighted until the next keypress.

I'm not sure why, but the keybind in the OP doesn't work for me, I still need to press escape twice:

keybind = escape=end_search

[rhodes-b]

search wraparound is a duplicate
#9762

The search bar should remember what was previously entered when it is recreated

This is how it works on linux because I made a PR to do so #9765 someone should port the same behavior over to macos

The text is selected, though, so typing in new text immediately replaces the old text. Again, how iTerm2, Safari, and other apps work.

This is also how it works on linux it selects all the text from the previous search but still highlights them like I noted above so typing one character will override the previous search, this was done in the original search PR by mitchell so someone should also probably port that to macos

[00-kat]

This discussion has a very large scope; let's track “Use of keybindings in focused search bar” at #11124 instead.

[joeshaw]

There are a few other minor things in here that (AFAIK) don't have tracking bugs. I was encouraged to open this as a discussion to see if we should spawn issues off of these.

• Use of keybindings in focused search bar - macOS search: Find Next / Find Previous (navigate_search:[next/previous]) don't work while search text field has focus #11124
• Escape should dismiss the search bar - I no longer think ghostty should do this
• The search bar should remember what was previously entered when it is recreated - There was a GTK issue for this (GTK: update search state from previous search on activation #9765) but I don't think there is a macOS one
• Search wrap around - Search wrap behavior #11449
• Search highlights don't work on selected text - Not sure if there's an issue for this, haven't tried tip in a while so I'm not sure if it's still an issue
• Search bar covers up matches - A nice-to-have, not aware of any issue for this.

[bo2themax]

• Search bar covers up matches - A nice-to-have, not aware of any issue for this.

For this, you should know that search bar can be dragged around.

[joeshaw]

Yeah, I mention this in the original description.

I understand that I can drag the bar around, but it would be nice if the viewport scrolled so that it didn't appear behind the search bar. I guess this might be tricky if the bar is at the bottom, but it's at least doable if it's at the top.

When I first encountered the issue, the problem was that the result was completely occluded by the search bar, so I had no idea that anything was even highlighted there. It was compounded by the fact that it was the first (last?) search result and wrapping wasn't implemented at the time.

[bo2themax]

Yeah, I mention this in the original description.

I understand that I can drag the bar around, but it would be nice if the viewport scrolled so that it didn't appear behind the search bar. I guess this might be tricky if the bar is at the bottom, but it's at least doable if it's at the top.

When I first encountered the issue, the problem was that the result was completely occluded by the search bar, so I had no idea that anything was even highlighted there. It was compounded by the fact that it was the first (last?) search result and wrapping wasn't implemented at the time.

Sry I missed that, yeah i think it's a good idea to scroll or to emphasize the search by some bam animation like terminal.app does

[00-kat]

Unless @bo2themax is fine with moving them straight to issues (the macOS maintainers and Mitchell are the only ones allowed to do that for macOS-related bugs/features), I think we should make a separate discussion for each thing.

My opinion is going straight to issues though; specifically:

Search highlights don't work on selected text

See #11243; if you can still repro and want to disagree, we should move to a new discussion in my opinion. Edit: I see bo2themax has opened #12509 just now.

The search bar should remember what was previously entered when it is recreated

If this is standard macOS behavior too, this should definitely be an issue to parallel Linux I think.

Search bar covers up matches

Y'all have already discussed this here so I think this is fine to move to an issue?

[bo2themax]

I'll mark this as completed with three additional issues opened: #12509, #12512 and #12516