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 (Naive search internals (core only) #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:

• Feature Request: "Hints" mode to select and act on arbitrary text patterns visible in the terminal #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.

[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