Search Scrollback History

[jsgf]

Is your feature request related to a problem? Please describe. There's no way to search the backscroll history, so finding something specific is tedious.

Describe the solution you'd like I'd like a mechanism to search for text in the scrollback history buffer. The ideal would be:

1. specify just a string, with options for whole-word and case sensitive/insensitive, or a regex
2. be able get immediate feedback on how many matches there are, and where they are in the buffer (eg a "match n of m", and/or markers in the scrollbar)
3. be able to jump around between them (ideally not completely linearly)
4. have the set of search results be updated live as new text is output

Describe alternatives you've considered Using a pager program with search

[wez]

cc: @dfrankland (but see also https://github.com/wez/wezterm/issues/106 for some bigger related picture stuff)

[bew]

There is a cool feature in kitty which allows you to send the whole scrollback buffer to a pager (or any program), to be able to have more powerful search/filtering without having to re-implement them in the terminal. Ref: https://sw.kovidgoyal.net/kitty/#the-scrollback-buffer

I think a basic exact-match/regex search can be good to have in wezterm, but the above method could be interesting to have as well?

[wez]

There is a cool feature in kitty which allows you to send the whole scrollback buffer to a pager (or any program), to be able to have more powerful search/filtering without having to re-implement them in the terminal. Ref: https://sw.kovidgoyal.net/kitty/#the-scrollback-buffer

I think a basic exact-match/regex search can be good to have in wezterm, but the above method could be interesting to have as well?

I'm not opposed to adding something like that functionality as a wezterm cli subcommand, but I'd rather that we flesh out the features inside wezterm first. One of the issues with piping scrollback into a command is that the command and the terminal emulator generally need to be running on the same machine and that isn't always the case--for example, I may be running the gui on a windows machine with an anemic set of shell/tools but be connected to a remote wezterm multiplexer. I'd like to have a consistent (and ideally decent!) experience for this sort of core feature and then enable the more advanced use cases later!

[wez]

I pushed a few more commits this morning; in addition to triggering the search UI you can now pre-fill the patterns from a key assignment; for example:

return {
  keys = {
   -- search for things that look like git hashes
   {key="H", mods="SHIFT|CTRL", action=wezterm.action{Search={Regex="[a-f0-9]{6,}"}}},
 }
}

You can use Regex, CaseSensitiveString and CaseInSensitiveString for the pattern type in these key assignments.

When the search overlay is active, CTRL-R (which isn't a configurable key) will cycle through the pattern types.

[github-actions[bot]]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.