Feature: search in the scroll buffer

[gaydenko]

Have not found the way to search the scroll buffer. Attempt to use konsole or alacritty search facilities just searches in the current screen.

[imsnif]

We unfortunately do not have this feature yet. PRs very much welcome!

[msirringhaus]

I would really like to have that feature as well. PR #566 seems to be dead in the water currently, possibly because it is unclear at the moment how to integrate the feature in the UI. Therefore I would like to rekindle the discussion here about that. (Note that I have not yet looked in the code much, so I'm arguing from an abstract point here)

I see 2 more or less obvious choices where the search could be located:

1. Have it's own mode next to "Move" and "Scroll".
2. Have it as a sub-function of "Scroll".

1. Own mode

Pro

• Conceptually, it is sort of a separate mode. When searching, the pane behaves differently to all other modes, accepting different commands, etc.
• Using it's own mode, modifiers ("case sensitive", "whole word only", "wrapping search", etc.) and commands ("Search next", "Search prev", ..) can easily be displayed
• The very obvious shortcut Ctrl+F is still free and not clashing with bash-commands
• Less keys to press to start searching

Con

• As mentioned above, it is only sort of a separate mode, as we would like to be able to use all the scrolling-commands inside a search. So we would have to copy the scroll-help over, or accept them 'silently' (hindering discoverability)
• There are already a lot of modes, so the menu might get a bit crowded

2. Sub-functionality of "Scroll"

Pro

• As above, it can also be viewed as an additional function on top of scrolling, so putting it there would also make sense.
• Menu would not be cluttered with ever more modes
• Scrolling commands are already displayed, helping discoverability
• Ability to modify the search, before starting to search

Con

• Needs some visual way to distinguish if a pane is in search mode or not
• The sub-menu of "Scroll" might get very crowded, if all search-commands and modifiers are added there as well.
• Maybe a bit less discoverable, because it is hidden behind the Scroll-mode
• More key presses needed to get there

I'm myself undecided on which variation I would prefer as a user. The choice might be obvious, when looking at the code, though.

[imsnif]

Hey @msirringhaus - happy to rekindle this discussion. Zellij has gone a long way since the previous issue and I feel this feature is one o the last stragglers in regards to basic usability.

Personally, I'm very much on the side of implementing this as part of Scroll Mode and perhaps changing the name to Search Mode. I think the scroll behaviour is more easily discoverable (seeing as we support mouse scrolling out of the box and have a UI indication for scrolling itself) and thus Search would be more helpful here. Not a must though.

I'm in favor of this being in the same mode because:

1. As you mentioned: not having an ever increasing number of modes
2. Even though ctrl-f (or some other shortcut) is not taken up in bash, it is for example taken up in vim (scroll one page down). In general, I think we've already taken up as many shortcuts as we should and we should try to make an effort not to interfere with users' workflows.

@TheLostLambda and I had the idea of implementing this (as well as a "search in all panes" functionality) as a built-in plugin (like the tab bar and status bar are currently), which would have the upshot of allowing us to potentially use ripgrep compiled to webassembly to do the heavy lifting - but the plugin system still needs a lot of work in form of providing these APIs. Which is to say: if you'd like to work on this, we can totally have this as a core feature for now and later on maybe offload it to a plugin. What do you think?

[msirringhaus]

Relabeling the Scroll Mode to Search Mode and putting everything there sounds like a good idea (or mayhaps even Search/Scroll Mode).

I'd be in principle interested in implementing this (be it core or plugin, but most likely core at first), but it would probably have to wait until end of June, when my company has its Hackweek again. I could use parts of the week for this feature. If somebody else wants to have a shot at it before that, even better.

[msirringhaus]

Ok, so I found some the time to play with this a bit. My current state is that I can search and highlight the current viewport with backward- and forward-search, using different colors for "the current selection" and "all other selections". Going through the rest of the scrollbuffer shouldn't be too hard, I hope.

But what I currently struggle with is the UX. I have relabeled the "Scroll mode" to "Search mode", but have kept the "Scroll mode" internally, as I like this function. Basically: "Search mode" without a search-term is identical to the current "Scroll mode". So: Ctrl+s goes to "Scroll mode" (same as before), but with a new action available: s for entering a search-string (done like "Rename pane"). When complete, we enter (internally) "Search mode" which is a superset of "Scroll mode" with additional functions: "next" and "previous" (as well as "ignore case", "wrap search", etc., which are not yet implemented). But this leads to quite a few keypresses to search for something:

Ctrl+s, then s, then enter search-string, then maybe some search-options like i, and finally n or p to actually search and start highlighting.

Any suggestions? Or am I making too big of a deal out of this?

[imsnif]

This sounds good to me, and is actually more than I'd have expected from an initial implementation - so no worries on that front. A few comments:

1. I'd try to keep things as consistently implementation-wise and code-wise, otherwise it might get a little confusing. So maybe have Search mode => Enter Search String mode => Search mode or some such?
2. Expanding on 1, it seems to me that we can probably keep most everything in the "outer" mode (the one we initially get to with ctrl+s) except for actually typing in the search term, right? Then if you press next/prev without a search term it's a noop (and we can maybe find a way to work it out in the UI). Wdyt? Will that simplify things?

[msirringhaus]

That could be done, yes. I opted for 3 different internal modes ("Scroll", "Enter search", "Search"), to be able to show the user if we are currently searching for something or "just" scrolling. Basically just a "Hide the search-options, if no search-string has been entered" done via different modes. But the first mode could probably be removed. (Although I somewhat like the hiding :-) ).

From a user-interaction PoV, it wouldn't really matter, I think: "n is there but a noop" vs. "n is not there, because it's a noop". The second one might be a bit clearer/less confusing (which is why I went for it).

[imsnif]

I see what you mean. Maybe it's just a naming issue then. Let's stay with your implementation then and explain the naming difference with some comments then?

[msirringhaus]

Yep, can do. It is all still very hacky and prototype-y anyways. We'll see what the next rainy weekend will bring :-).

[andreimatei]

@msirringhaus has it been raining? :P

[msirringhaus]

@msirringhaus has it been raining? :P

'Sadly', no :-) But HackWeek is in 20 days. I should probably open a WIP-PR soon, though, with what I already have, so it can get a quick pre-review.

[iogrt]

I saw these release notes: https://www.reddit.com/r/commandline/comments/v7kqt2/zellij_0300_released_search_terminal_scrollback/ has this been implemented?