Search scrollback

[mitchellh]

A major missing feature is the ability to search scrollback, i.e. cmd+f on Mac, ctrl+F on Linux. This issue can be implemented in multiple steps, not just one giant PR:

• Core search functionality in src/terminal (#2885)
• Make core search work simultaneously to PageList read/write to allow multi-threading
• Implement multi-threaded search, including data modeling for notifications of matches
• Search UI, glue in apprt

We can also support search only in certain modes as long as the apprt glue is all there for someone to come along and finish it up. For example, only macOS, Linux+GTK, etc.

[amadeus]

Would be cool to fake what terminal emulator in vim does -- where you can pause the existing session ctrl+w N, and move around the buffer with vim commands for searching and highlighting, then press i to return back into the session. Here's an example video (not saying the commands should be the same to pull this off, just using that as an example):

CleanShot.2023-07-07.at.00.09.42.mp4

[andrewrk]

Looking forward to this feature - I missed it yesterday when I had a lot of output from a command and wanted to search for the word "fail".

[vancluever]

Kitty has a a pretty novel approach here that I've actually really enjoyed - ctrl+shift+h actually sends the scrollback to a pager (e.g. less). I've found this much less confusing in comparison to others (like iTerm's).

This also lets you take advantage of the pager's features and can be tailored to a certain user's preference without minimal load on our side.

[gpanders]

Kitty has a a pretty novel approach here that I've actually really enjoyed - ctrl+shift+h actually sends the scrollback to a pager (e.g. less). I've found this much less confusing in comparison to others (like iTerm's).

FYI Ghostty has this too, bound to Cmd-Shift-J on macOS and Ctrl-Shift-J on Linux.

It works slightly differently than Kitty in that it puts the temp file path to the captured scrollback on the command line rather than opening it in a pager directly.

[benwaffle]

Once we have search, searching via regex would be really nice to have. I've been finding myself search for exit [^0] a lot recently.

[mattpolzin]

Kitty has a a pretty novel approach here that I've actually really enjoyed - ctrl+shift+h actually sends the scrollback to a pager (e.g. less). I've found this much less confusing in comparison to others (like iTerm's).

FYI Ghostty has this too, bound to Cmd-Shift-J on macOS and Ctrl-Shift-J on Linux.

It works slightly differently than Kitty in that it puts the temp file path to the captured scrollback on the command line rather than opening it in a pager directly.

One nice thing about Kitty's implementation is you can even use it as a program is actively running and potentially still outputting text; new text doesn't automatically get fed into your pager but you don't need to wait until a command finishes to use the pager functionality.

I'm not immediately sure if that would be equivalent in behavior to

1. Pause current execution
2. Send to background
3. Open ghostty's scrollback file in pager
4. On quit, bring task to foreground if still running

[pjz]

I'm used to screen/tmux behavior here: ctrl-A,[ puts you into 'scrollback mode' where you can then use the keyboard (vi-keys) to scroll up and down, and then even hilight some text and put it into a clipboard where you can then paste it with ctrl-A,].

I don't think it updates the buffer while scrolling, though... but I don't see why it couldn't just extend it downward.

[yankcrime]

Personally I'd rather this stuck to OS-native conventions for search functionality as well as look and feel. I don't think implementation-specific idiosyncrasies are a good idea since a lot of folks will have differing preferences and expectations.

The implementation along the lines of what's provided by Terminal.app or iTerm would be fine since that easily lets you search the scrollback buffer in a way that doesn't affect any additional output.

[andrewrk]

Some prior art:

It... suffices.

[peteschaffner]

@qwerasd205 Are you working on this now? I'd be happy to help out on the macOS UI front.

(I mentioned this in Discord but just surfacing it here too since I rarely check over there.)

[qwerasd205]

I am working on laying some groundwork for this with a basic implementation of the search functionality - focused mainly on proper threading for the search and creating a good interface for the UI code to talk to with minimal coupling, so that in the future we can improve the performance of the search (if necessary) by changing the algorithm and/or data structures used for the searching. I'll open a draft PR once I've got the first "technically functioning" version of the code.

Right now it's in too early of a state to really create UI for.

[ferdinandyb]

Personally, "native" in a terminal means "vi-like" to me :) I also think kitty's approach is pretty flexible and can probably be used along side a more classic ctrl-f as well. I also quite like contour's vim-like normal mode tbh.

But why I actually wanted to comment is related to generic search, but a bit more specific: sometimes you actually see what you need on screen, but want to quickly copy/paste/execute it without a mouse. Back when I was using kitty I used hints a lot, and in tmux I use tmux-butler. Behind the scenes these use cases could be regex-searches constrained to the currently visible text, although obviously the UI would be quite different. Imho especially quickly opening links in the browser and copying paths to the prompt without a mouse is really useful.

[sluongng]

I wanted to file a feature request for something like Kitty Hints like @ferdinandyb mentioned.
https://sw.kovidgoyal.net/kitty/kittens/hints/

However, after a bit of searching, I figured this issue is a prerequisite for such a hinting system.

[andrewrk]

More prior art:

Konsole has a pretty decent implementation if you want something to draw inspiration from.

[rmacklin]

Re:

I wanted to file a feature request for something like Kitty Hints like @ferdinandyb mentioned. https://sw.kovidgoyal.net/kitty/kittens/hints/

However, after a bit of searching, I figured this issue is a prerequisite for such a hinting system.

Mitchell confirmed on Discord that this issue isn't a prerequisite for a "hints" feature - so I've gone ahead and created a separate issue to specifically discuss that feature request:

• #2012

[qwerasd205]

I am working on laying some groundwork for this with a basic implementation of the search functionality - focused mainly on proper threading for the search and creating a good interface for the UI code to talk to with minimal coupling, so that in the future we can improve the performance of the search (if necessary) by changing the algorithm and/or data structures used for the searching. I'll open a draft PR once I've got the first "technically functioning" version of the code.

Right now it's in too early of a state to really create UI for.

I got sidetracked from this shortly after starting work on it, but to summarize the architecture I landed on for the search thread:

Search Thread

Data

• Search results: Doubly linked list of spans represented by pairs of pins
• Active area search results: Separate results list for content in the active area, since it needs to be repopulated whenever the active area's content changes (dirty tracking logic could be added in the future if necessary)
• Search pattern: Struct containing info used to perform the search (in my prototype it's just a string and a flag for whether to be case insensitive)

Messages

• Search pattern updated; if new pattern is different from old pattern, reset search results, and if currently mid-search, reset search back to start (either top or bottom of scrollback, depending on which direction the search is performed in)
• Begin search; start searching, intermittently yielding to the event loop. In my prototype I use a line iterator. If no iterator exists, create a new one, take a line from it, apply the pattern, add any results to the results list, notify the surface - if the iterator is out, we're done searching, notify the surface of this fact - then check the mailbox again.
• Stop search; self explanatory.
• Active area updated; if not currently searching, do nothing - otherwise throw out current active area results list, apply the search pattern to all lines in the active area, update the results list, notify the surface.

Whenever the surface is notified of new search results, it updates its display accordingly, reading from the results list should be thread safe.

[rcalixte]

More prior art from terminator (which is currently based on GTK 3).

Search appears at the bottom of the active window/split when the binding is activated and is hidden on Esc. And when the search is cancelled, the scrollback resets to the bottom.

[PatrickF1]

Hi Mitchel, I noticed you removed the core label. Does that mean you don't plan on building this before the 1.0 release? Just curious is all.

I think I speak for many of us that this is only major feature missing from our previous TE but the other niceties, speed, and stability Ghostty provides easily makes up for it :)

[mitchellh]

No, the core label just isn't meaningful anymore (the label no longer exists). I'm not sure this will make it before 1.0 but I am going to try.

[PatrickF1]

Thank you!!!!!!!!!!!!! Good luck!

[benwaffle]

FWIW this is one of the main reasons I'm still using iTerm 2

[markpapadakis]

+1 for the importance of this feature; I didn't realize how much I needed it until I needed it

[samuelgozi]

I know that this doesn't help much, but I think that this is a vey important feature.
Probably 5 mins after installing Ghostty, while customizing it I wanted to search the output of ghostty +show-config --default --docs, so I believe it will be noticeable if it were missing on release.

[mitchellh]

I want to note that this isn't going to make it in for the 1.0 release, unfortunately.

I started working on it and made significant progress but if I am to keep my 2024 promise for Ghostty 1.0, then this will have to slip. I'm sorry! I know this is an important feature for many and it's a priority to come into a subsequent feature release.

I originally considered this a blocker for 1.0 but the reality is that we ended the beta with almost 5,000 testers and the vast, vast majority found Ghostty productive and perfectly usable without this feature (me included, using it daily for 2 years!). So, I'm not downplaying the importance of this issue but I think it's okay to ship 1.0 without this and add it after.

[GoldsteinE]

Prior art from foot: this dimming / highlighting looks really nice IMHO.

[aofei]

OT: Genuinely think this issue should be pinned. 👀 (Been asked about this feature several times today)

[mitchellh]

OT: Genuinely think this issue should be pinned. 👀 (Been asked about this feature several times today)

Good feedback. Pinned!

[weeheavy]

I'd love to see the elegance of Alacritty's search:

• cmd+f opens a small one-line search at the bottom
• enter scrolls foward through search results
• shift+enter scrolls backwards

[nervenes]

I'd like the UI for this to be native, similar to Terminal.app

[sethgrid]

I just did a full grep of my file system looking for a breadcrumbs and then found out I can't search through my results. I was able to cmd+a cmd+c tab to vscode and cmd+p and then cmd+f. I am constantly using cmd+f on my terminal :(

[AdrielVelazquez]

I wanted to provide some recipes for people waiting for this

Searching by piping to fzf

cat <ctri + shift + j> | fzf
cat /tmp/lxFj1l2gJE_1KUpyQWkPWQ/history.txt | fzf  (example command)

Searching via Neovim

Make sure that the default for xdg-open (linux) or open (mac) is set to nvim or whatever code editor you use

Example in NixOs

  xdg.mime.enable = true;
  xdg.mimeApps.enable = true;
  xdg.mimeApps.defaultApplications = {
    "text/plain" = [ "nvim.desktop" ];
  };

Then create a new keybinding in ghostty

keybind = ctrl+f=write_scrollback_file:open

Using ZSH (Janky)

This is essentially just looking for the most recent history file. Sometimes the most recent output isn't there since it's dependent on calls to write_scrollback_file. And that's not a simple binary you can call.

        function jank_scrollback_search() {
          # Find all files named history.txt in /tmp
          local files=$(find /tmp -name "history.txt" -print0 | xargs -0 stat -c '%Y %n' | sort -rn | head -n 1 | awk '{print $2}')

          if [[ -z "$files" ]]; then
            echo "No history.txt files found in /tmp" >&2
            return 1
          fi
          local trimmed_files=$(echo "$files" | tr -d ' \n')

          cat $trimmed_files | fzf
        }

        zle -N jank_scrollback_search

        # Bind the widget to Ctrl+f
        bindkey '^f' jank_scrollback_search

[elCarlosSantiago]

I've setup my new ghostty terminal and am really enjoying it. Unfortunately, wont be daily driving it until this functionality is ready. Key part of my workflow

[Tenzer]

To elaborate on the earlier comment, a workaround for this currently exists in that you can bind keys to open an editor with all the text from the current terminal in it, which can then be searched through.

The default keybinds related to this are:

• super+shift+j: write_scrollback_file:paste
• super+alt+shift+j: write_scrollback_file:open

The documentation for write_scrollback_file can be found here: https://ghostty.org/docs/config/keybind/reference#write_scrollback_file.

One slight downside with these, as they are now, is that they only write contents outside the visible area to the temporary file, so they don't help if you want your search to also include what is currently shown.

If you want that included, you instead want to add a keybind that use the related write_screen_file method, as it includes all the contents in the tab.

I personally find write_screen_file more useful than write_scrollback_file so I have overridden the above mentioned keybinds to use that instead:

keybind = super+shift+j=write_screen_file:paste
keybind = super+alt+shift+j=write_screen_file:open

This allows me to press super+alt+shift+j which then opens the default editor for .txt files (at least on macOS) with the contents of the terminal, which can then be searched through.

[tednaleid]

for the workarounds, is there any way to script the calls to write_scrollback_file and write_screen_file or can they only be triggered via keybinds?

Currently, if I add this keybinding for writing the name of the screen file to the terminal:

keybind = super+shift+k=write_screen_file:paste

Then, I can manually type (on a Mac):

cat <cmd + shift + k> | fzf

If there were some way to trigger those actions without having to press the keybinding, I could do something like:

cat <(ghostty --run-action write_screen_file:paste) | fzf

and assign that to a script/alias

That'd give me almost all the scrollback searchability I need

[xzbdmw]

and assign that to a script/alias

see #3708 (comment)
I wish ghostty could somehow preserve escape sequence colors so I can use :term cat something in nvim.

[msharran]

I find this feature in kitty very useful rather than using cmd+f. I have tried both and this was practically useful for me. (Genuinely want to understand how others feel about this also)

When my unit test output is very long, i just open the last command output in LESS and troubleshoot.

If the cmd's output I am looking for is few prompts before, in kitty, I would navigate to it using keyboard shortcuts (ghostty can also do this) and right click holding kitty_mod to open in LESS. (See here)

In ghostty, it would be useful to redirect write_selection_file output to any program's STDIN.

Like

keybind = "super+shift+w>s=write_selection_file | less"

[marianposaceanu]

Based on the previous comments - I'm currently using this on macOS:

keybind = super+f=write_screen_file:open

This way it won't stop me from using Ghostty as a daily driver.

[DontEatOreo]

I'm surprised copy isn't an option. Wouldn't this partially solve the issue since you can just quickly take a "snap," go to another window, manually paste the path, and open it in your editor?

For example, right now, if you have a TUI program or you're in an interactive state, the only option you can use is open, since paste will cause an interaction

I'm personally rooting for #189 (comment). This seems like one of the nicest implementations for such feature

Since this reply will ping a lot of people, I might as well just ask: Is there any workaround to still use open but to give it a custom program instead of it grabbing the default text editor?

[xzbdmw]

I'm surprised copy isn't an option.

FYI you can use cmd+a + cmd+c to copy all the text.

[Stono]

I've setup my new ghostty terminal and am really enjoying it. Unfortunately, wont be daily driving it until this functionality is ready. Key part of my workflow

Yeah I second this. I've really being enjoying Ghostty but found the inability to do cmd+f pretty debilitating in my day to day workflow. It's like the only missing piece of the puzzle for me! I'm kinda sad to have to go back to iterm for now!

[jdx]

this issue is the most thumbed several times over. There are likely hundreds of people subscribed to it. It's not helpful to post messages here simply saying it "doesn't fit your workflow". @mitchellh knows this is necessary. He'll work on it when he can I'm certain. Let's try to keep the discussion to helpful information.

[Stono]

I was actually, primarily, complimenting the awesome terminal this is because it quite literally is almost perfect and I'm quite excited by that. As the issue has been open for 18 months I perhaps wrongly made an assumption that it probably wasn't moving forward (at least any time soon) so was just adding my perspective to it.

I'm sorry for sharing my experience with Ghostty and I'm sorry you took such offence to that mistake. It's such a shame GitHub (and tech in general) is so hostile these days, people just seem to assume the worst in each other.

Merry Christmas!

[jdx]

I apologize if that came across as hostile, it was not meant to, nor what is it targeted at you since you're not the only one in recent days to have done this. My goal is simply to keep the discussion here helpful since it has a lot of eyeballs on it and we don't want to add to the noise.

[Stono]

That is completely fair, and I understand - thanks. 🤝

[eaverdeja]

keybind = super+f=write_screen_file:open

Did anyone manage to get this to open in vim/nvim? I have nvim as my default editor on MacOS, but for some reason ghostty still opens the buffer in the default MacOS text edit.

[martensson]

keybind = super+f=write_screen_file:open

Did anyone manage to get this to open in vim/nvim? I have nvim as my default editor on MacOS, but for some reason ghostty still opens the buffer in the default MacOS text edit.

It uses the default editor of MacOS, not your $EDITOR. There is an OS setting to modify it globally from the default (need to Google it), but probably better to change it to MacVim rather than a CLI-tool in this case.

[eaverdeja]

Thanks @martensson ! I got it to work with Neovide by setting the default editor via Launch Services:

 defaults write com.apple.LaunchServices/com.apple.launchservices.secure LSHandlers -array-add '{
    LSHandlerContentType = "public.plain-text";
    LSHandlerRoleAll = "com.neovide.neovide";
}'

[elCarlosSantiago]

Thanks @martensson ! I got it to work with Neovide by setting the default editor via Launch Services:

 defaults write com.apple.LaunchServices/com.apple.launchservices.secure LSHandlers -array-add '{
    LSHandlerContentType = "public.plain-text";
    LSHandlerRoleAll = "com.neovide.neovide";
}'

Great solution, officially daily driving it now. Here's the command for vscode, can be done for any editor.

 defaults write com.apple.LaunchServices/com.apple.launchservices.secure LSHandlers -array-add
'{
    LSHandlerContentType = "public.plain-text";
    LSHandlerRoleAll = "com.microsoft.VSCode";
}'

[justyn]

Regarding the implementation of search in Ghostty.

Different terminals have different approaches to search. For example, Wezterm has both Copy Mode and Quick Select Mode.

I personally would really value something that emulated my (Lazy)Vim configuration - not just basic Vim motions but custom textobjects, seeking with flash.nvim etc. Obviously I can get part of the way there with write_selection_file but it is a bit clunky and doesn't update with new output.

Given that it would be bloated for Ghostty implement all the different approaches, could it instead hand over to an external tool for the search? That would allow experimentation and innovation in this area without affecting Ghostty's code.

Perhaps there is something more streamlined than dumping the scrollback to a file then opening it in an editor... I haven't figured out the mechanics (a pointer? an emulated file?). Or is write_scrollback_file the only reasonable way it can be done?

[zxt-tzx]

Thanks @martensson ! I got it to work with Neovide by setting the default editor via Launch Services:

 defaults write com.apple.LaunchServices/com.apple.launchservices.secure LSHandlers -array-add '{
    LSHandlerContentType = "public.plain-text";
    LSHandlerRoleAll = "com.neovide.neovide";
}'

Great solution, officially daily driving it now. Here's the command for vscode, can be done for any editor.

 defaults write com.apple.LaunchServices/com.apple.launchservices.secure LSHandlers -array-add
'{
    LSHandlerContentType = "public.plain-text";
    LSHandlerRoleAll = "com.microsoft.VSCode";
}'

not sure if this applies more generally, but I needed to restart my Mac for this to take effect. thanks for the suggestion!

[github-cloud-cd]

On MacOS the defaults command requires you to log out and back in for it to take effect. A reboot will also work.

[rmacklin]

Regarding the implementation of search in Ghostty.

Different terminals have different approaches to search. For example, Wezterm has both Copy Mode and Quick Select Mode.

For quick select mode, there is a feature request here (the title is based on the analogous feature in kitty):

• #2394

[Stono]

For some reason I couldn't get the commands above to work, but duti from brew helped:

brew install duti
duti -s com.microsoft.VSCode public.plain-text all

I didn't need to log back in for this either.

If you need to find the plist identifier for your desired app, do:

/usr/libexec/PlistBuddy -c 'Print CFBundleIdentifier' /Applications/Visual\ Studio\ Code.app/Contents/Info.plist

I failed to get it to open anything not installed as an Application though (for example i have nvim installed via brew).

[mmerickel]

As a new user coming from iterm+tmux and trying to use ghostty as a replacement the main hangup I've run into is around scrollback management. With tmux I can use ctrl-a-[ to enter a scrollback mode where I can use ? and / to search the scrollback, as well as hjkl to navigate, ctrl-u to page up and ctrl-d to page down, and space to start a selection, and enter to finish a selection, copying it to the clipboard. I think something like this would require a new scope for key-bindings like scrollback alongside the current all and global scopes.

I would really love this modal capability in ghostty with the added benefit that whatever y'all do would also work well with the mouse where tmux tends to struggle.

[escluse]

Great solution, officially daily driving it now. Here's the command for vscode, can be done for any editor.

 defaults write com.apple.LaunchServices/com.apple.launchservices.secure LSHandlers -array-add
'{
    LSHandlerContentType = "public.plain-text";
    LSHandlerRoleAll = "com.microsoft.VSCode";
}'

not sure if this applies more generally, but I needed to restart my Mac for this to take effect. thanks for the suggestion!

You can do this using Finder:

1/ select "Get Info" on any .txt, etc. file
2/ change the "Open With" default to any macOS Application

However, this doesn't work for $EDITOR and it's not worth creating a .app wrapper bundle given that it launches an entirely new instance.

[m4saurabh]

I like the way kitty does it, it exposes the scrollback buffer and you pipe that to any program, like less and more importantly neovim so you can move around with vim bindings without creating a subpar version of them.

[tmccombs]

FWIW, wezterm has a feature similar to kitty's which allows you to send the buffer to an external program. But also has it's own search and navigation modes.

[leo-paz]

I just want this to work like warp :)

[m4saurabh]

@leo-paz you should share a video of it

[JonasGruenwald]

I like the way kitty does it, it exposes the scrollback buffer and you pipe that to any program, like less and more importantly neovim so you can move around with vim bindings without creating a subpar version of them.

I think it's really nice that ghostty does tabs via UI like most other software (file explorer, browser etc.) using the common OS hotkey for it, rather than pushing users towards something like tmux or zellij.

Similarly I'd prefer if scrollback search was done via UI as well, so cmd/ctrl+f works the same as in all other software, rather than pushing you to pipe to another utility for searching, even if it's how you would otherwise commonly search a text buffer from within the terminal.

It's just nice to have common functionality work the same across all software in my opinion, makes things intuitive to use.

But I suppose nothings speaks against also exposing the scrollback buffer for piping in addition to that.

[bofm]

iTerm highlights the searched pattern in live mode. This is handy when tailing some log and want to highlight something important but also not throw away the rest of the log as grep would do it.

[justyn]

I like the way kitty does it, it exposes the scrollback buffer and you pipe that to any program, like less and more importantly neovim so you can move around with vim bindings without creating a subpar version of them.

Thanks @m4saurabh for the hint on this Kitty functionality.

From there I also discovered this incredible Neovim plugin which integrates with the Kitty scrollback buffer and provides some extra handy functionality.

Here is part of a demo by the author (starting at 9:05) showing switching seamlessly between live Kitty and the scrollback buffer within Neovim. Note the little flash of the text redrawing but other than that you wouldn't know that you had left the terminal!

Most relevant to this discussion is that the author also details here (same video from 4:50) various approaches to getting the scrollback buffer into Neovim, starting with writing to a file then eventually settling on Kitty's built-in remote calls like get-text.

It will be great if Ghostty can also allow for this kind of deep integration which offers the best of both worlds of native terminal and your raw custom Neovim power, plugins and all.

But I suppose nothings speaks against also exposing the scrollback buffer for piping in addition to that.

I completely agree this kind of capability should be alongside rather than instead of built-in search.

In the meantime thanks to the great discussion in this thread I think I'm switching to Kitty for a while :-)

[joe-chandler]

iTerm highlights the searched pattern in live mode. This is handy when tailing some log and want to highlight something important but also not throw away the rest of the log as grep would do it.

Indeed, with how much time i spend SSHd into servers, this feature pairs well with all of the other bazillions of utilities i have to use on live tailing of screaming logs. On OSX, i had to go back to iTerm2. Still using Ghostty on my personal laptop.

[quinncomendant]

Another use for scrollback search is to highlight matching strings to make screenshots that I send to colleagues. This is extra useful with regex search, to allow highlighting different types of strings. I use this often – here's an example screenshot.

[withnale]

The ability to search scrollback and the ability to pipe scrollback to arbitrary commands are two different pieces of functionality. It would be nice to have both but this card is specifically about the former.

[CanRau]

iTerm highlights the searched pattern in live mode. This is handy when tailing some log and want to highlight something important but also not throw away the rest of the log as grep would do it.

use(d) this all the time, currently trying to main ghostty tho 🤓 and hit the missing search feature pretty quickly 😅

[tuananh]

Another use for scrollback search is to highlight matching strings to make screenshots that I send to colleagues. This is extra useful with regex search, to allow highlighting different types of strings. I use this often – here's an example screenshot.

agreed. this is a very common use case.

[justyn]

The ability to search scrollback and the ability to pipe scrollback to arbitrary commands are two different pieces of functionality. It would be nice to have both but this card is specifically about the former.

That's a good point. I've opened a discussion for a new feature request here: #4870

[createchange]

For folks wanting to highlight and not lose surrounding context, follow output streams, etc. - you can take a look at ack (https://beyondgrep.com/).

[ollema]

For folks wanting to highlight and not lose surrounding context, follow output streams, etc. - you can take a look at ack (https://beyondgrep.com/).

or just rg --passthru with ripgrep

[bofm]

ack or ripgrep

Those are one-off. Can't re-search if the input isn't saved.

[ollema]

ack or ripgrep

Those are one-off. Can't re-search if the input isn't saved.

this is just a workaround for those missing search just to highlight words before sending screenshots

[nachoal]

Any workarounds to cmd + f for searching for words in previous stdout that you can recommend for mac user?

[fxsalazar]

I use fzf:
fzf < [cmd + shift + j]

[mdeeks]

Any workarounds to cmd + f for searching for words in previous stdout that you can recommend for mac user?

This config below opens your previous output and makes it searchable in your default text editor (I use Sublime). This has been working well for me.

cmd+f = Open your entire scrollback history in a text editor so you can search

cmd+shift+f = Open whatever you have selected in your scrollback history in a text editor

# Search entire scrollback history in default text editor
keybind = cmd+f=write_screen_file:open

# Search Selection
# HOWTO: Cmd+triple_click to select your last output then press cmd+shift+f to search it
keybind = cmd+shift+f=write_selection_file:open

# RECOMMENDED: Set this to something big so you can capture all of your scrollback
scrollback-limit = 20000000

# How to change your system-wide default text editor to Sublime
# brew install duti
# duti -s com.sublimetext.4 public.plain-text all

Update: Switched to using write_screen_file which actually includes the current screen as well as all of the scrollback. So now you just hit cmd+f and it opens in your editor. Then cmd+f again to search.

[pioz]

Is there an ETA for this feature by any chance?

[andoniabedul]

Is there an ETA for this feature by any chance?

@pioz the ETA is the time that you can fix the bug by yourself; if you don't know how, wait with patient without asking when it will be ready. :) this is an open source terminal with no remuneration. Sorry for the hard response btw.

[pioz]

Is there an ETA for this feature by any chance?

@pioz the ETA is the time that you can fix the bug by yourself; if you don't know how, wait with patient without asking when it will be ready. :) this is an open source terminal with no remuneration. Sorry for the hard response btw.

@andoniabedul Yes, absolutely, I completely agree with you. I only asked to check if there might be any updates, as this feature is quite important to me. Let’s say that a simple "there's no ETA currently" might have come across as a bit kinder, but it's all good nonetheless. Thanks for the information!

[RoyTinker]

I have loved using Ghostty for the last several weeks, but the lack of scrollback searching is forcing me back to iTerm2. Hope to be back soon! :)

[coltnz]

The good enough workaround is : #189 (comment)

[exsesx]

The good enough workaround is : #189 (comment)

Based on the previous comments - I'm currently using this on macOS:

keybind = super+f=write_screen_file:open

This way it won't stop me from using Ghostty as a daily driver.

I haven’t explored this workaround in depth yet, but using write_screen_file:open on macOS opens the TextEdit app instead of nvim in Ghostty. While TextEdit could work, I’d prefer to wait for this feature to be implemented directly in Ghostty. I’m open to configuring it further, but for now, it doesn’t feel very user-friendly. Thanks for sharing the workaround, though!

[evandam]

Agreed, I think opening it with $PAGER would make for a pretty good user experience if it's possible until a more native scroll bar.

[sassanh]

Do we need native pagination at all? Why should each terminal emulator implement its own pagination, scrollback, search, etc., with its own design preferences? We already have lots of pagination tools like less, more, bat, pg, most, etc., and lots of editors that have view mode like vim, emacs, neovim, etc.

Personally, I would rather press a key combination and see my scrollback opened in my neovim with all my plugins, in which I have full control over the content, and the key bindings are all already in my muscle memory. That's what I was doing in Kitty for years.

If one prefers another pagination tool, they can open it in that tool, and we don't need to re-implement a semi-vim or semi-emacs for this purpose.

One could set it in the configuration, and it can use $PAGER by default. If $PAGER is not provided, it will default to less.

[Crocmagnon]

I would rather press a key combination and see my scrollback opened in my neovim

That’s your preference, and it’s fine. But there are others who prefer having a native search feature. That doesn’t prevent your workflow from still working, it’s just another option.

[Jackenmen]

Ghostty whole gimmick (or well, one of the main ones) is that it's supposed to feel native to the OS it's running under and I don't think that requiring use of a pager for search and scrolling gives you that. It perhaps feels native to the shell (piping between tools is very natural) but not to the OS which, if it were any other app, would give you a regular scroll and search functionalities.

[haseeb-heaven]

I find this feature in kitty very useful rather than using cmd+f. I have tried both and this was practically useful for me. (Genuinely want to understand how others feel about this also)

When my unit test output is very long, i just open the last command output in LESS and troubleshoot.

If the cmd's output I am looking for is few prompts before, in kitty, I would navigate to it using keyboard shortcuts (ghostty can also do this) and right click holding kitty_mod to open in LESS. (See here)

In ghostty, it would be useful to redirect write_selection_file output to any program's STDIN.

Like

keybind = "super+shift+w>s=write_selection_file | less"

keybind: unknown error error.InvalidAction

[haseeb-heaven]

Based on the previous comments - I'm currently using this on macOS:

keybind = super+f=write_screen_file:open

This way it won't stop me from using Ghostty as a daily driver.

This only opened output into Text editor, This is a hack not actual feature we wanted

[ttilberg]

Opening the scrollback buffer hasn't worked well for me, as most of the time when I'm wanting to search for specific output, it's during a running process, such as a Rails server, or Scrapy run. It adds a more dissonance to the process. I kept getting burned in situations where it was hard or impossible to reasonably check something compared to iTerm and had to switch back for now.

I hate to ask for features in an open source project; it would be cool if there was a feature bounty or something. I'd put a tip in the tip jar for this. Let me know if there's somewhere I can put some money where my mouth is; perhaps others would follow.

[e-kotov]

it would be cool if there was a feature bounty or something. I'd put a tip in the tip jar for this. Let me know if there's somewhere I can put some money where my mouth is; perhaps others would follow.

good point, I would join.

[gorkunov]

You may not realize it, but this is primarily the work of one incredible individual. Mitchell likely has enough financial security for the rest of his life and even for his children’s future (I believe).

Unfortunately, this means we can’t motivate him to take action simply by offering to pay for it. At this point, it’s all about time and priorities, and unless Mitchell finds someone else willing and able to take on this work, progress may remain limited.

[blacktop]

Mitchell is very aware of the importance of this feature and will solve it in a perfectly appropriate way that fits in with his ghostty design language and UX. He's focusing on stability and bug fixes for v1.1 and then will focus on this possibly for the version following that. Nothing left for us to do except be patient or open a PR ;)

[AdrielVelazquez]

This is the PR--which should definitely not be used--of how I'm getting around it for now.

I essentially added a new option to WriteScreenAction which will open up the scrollback in your defined $EDITOR so that it stays within the terminal.

This is doesn't fully leverage the way that ghostty or termio expect you to launch this command, but it was more me getting familiar with the codebase in general.

PR New Write Screen Action

This allows the new keybind of ctrl + shift + f to open the scrollback in whatever you use as $EDITOR

[jamesharr]

Specific designs aside, the big 2 use cases I have:

1. searching for something in my scrollback.
2. highlighting all instances of a specific field. As mentioned above, searching for "FAIL" or "ERROR" is probably a common, but it depends on what I'm doing.
   • Sometimes I might want to highlight a specific log term, so using a static configuration might not be appropriate.
   • I also wind up glancing at the scrollbar to look for when terms may have scrolled by

It's possible that these are better as separate actions/features, but that's how I use it today. Sometimes I want to find go something, sometimes I just want to draw my attention to certain strings while I run other stuff.

[frejonb]

This issue has multiple workarounds for this functionality but I'm genuinely interested in how @mitchellh's workflow looks like to not need this functionality (based on the previous reply):

I originally considered this a blocker for 1.0 but the reality is that we ended the beta with almost 5,000 testers and the vast, vast majority found Ghostty productive and perfectly usable without this feature (me included, using it daily for 2 years!). So, I'm not downplaying the importance of this issue but I think it's okay to ship 1.0 without this and add it after.

[jcollie]

I don't know what Mitchell's workflow is, but since the dawn of time when TTYs stopped recording everything on paper we've gotten by just fine with tools like tee, more, and more recently less.

[martensson]

I don't know what Mitchell's workflow is, but since the dawn of time when TTYs stopped recording everything on paper we've gotten by just fine with tools like tee, more, and more recently less.

While I partly agree and often use grep, ripgrep, less, vim -, etc., it is not always feasible. Not all applications quit with an output that can be piped to another tool to search certain keywords. Sometimes I just forget before running a command, and need then to run it again to parse the output (and that is not always possible, and some commands can take minutes to run). Other times the output is just unpredictable and I need see it before searching.

And in my case I often benefit from the context and update my search patterns live while scrolling. These are some of the cases where terminal search is super useful, and something I use daily working as an SRE where I spend a lot of time reading logs and app outputs. It is also the reason I personally switch back and forth between Ghostty and iterm2, and the only thing keeping me back from doing a full switch.

[hayesgm]

Curious on using cmd+shift+j or keybind = ctrl+f=write_scrollback_file:open, can either of these retain ANSI control codes? It feels hard to lose colors when exploring large scrollbacks.

[gregopet]

where I spend a lot of time reading logs and app outputs.

Exactly - it's the case where you find data X in the output, correlate it with Y and eventually end up at Z. You don't want to rerun your whole activity for that and it's great not to have to think about these things beforehand (oh no, I noticed a weird bug but I wasn't piping my output to less 😱 )

[trashhalo]

For my own workflow ive been managing to get by using > to dump long outputs into a file then nvim that file.

run_chatty_thing > tmp.log
nvim tmp.log

[Syphdias]

Please stop suggesting workarounds. There are enough of it in this thread. I believe there are situations where theses workarounds (|less, tee/>, etc.) don'te work but I won't mention them to not trigger a response that there is in fact a workaround.

The only things I — and potentially other subscribers to this issue — am interested in this issue are contributions regarding the resolution.

I would suggest closing the issue to discussion.

/rant over, sorry