Generalized searching of commits, diff text, etc

[alexmaco]

Is your feature request related to a problem? Please describe.
Often views of diffs, or file blames, or commit lists are very long. Quickly finding some element or piece of text is a common need, and a very useful feature.

Describe the solution you'd like
I'd like a generalized search functionality. The input text should be visible in the command bar. Any view that has text items should eventually implement searching and/or filtering (help included). Ideally, it should be unified with the fuzzy file finder, but it doesn't have to be.

• When I press /, type some text, and hit return the current view should scroll to the first textual match, and that textual match should be distinctly highlighted.
• n and Shift-n should cycle between matches, changing the highlight.
• optionally, Shift-/ (?) can search in reverse
• Ctrl-/ (or another combo) should instead filter the view by the text input.
• A view that supports filtering, should make it clear that it is in a filtered mode, possibly by changing highlights (fuzzy file finder does a good job here, and something like that would be nice for commits, or filtering diff chunks that contain that substring)

Describe alternatives you've considered
Using tig 😄

Additional context
Similar issues: #429, #449, #990, #1113, #1350
There seems to be some effort and interest already in this, given gitui has a nice fuzzy file finder, #672 was being worked on.
After some local prototyping, I'd suggest that search/filter input be a per-app global, and only be available when the current component signals it knows how to search/filter. This may imply that search/filter either be added to the Component trait, or be treated like an event.

[extrawurst]

see also #672

[alexmaco]

#672 would definitely be good to have.

The one piece still missing from that design is getting the search action from a unique global component (the search bar) down the tree to the Component that signals it has search support (when focused).

This could work by adding some internal action to the Component::event dispatch path (which might be elaborate, though simple), or by adding a side-bus, which leads to some necessity of id tracking, maybe something like an ECS for components. The ECS approach would also cut down on the repetition of code for dispatching events and handling subcomponents.

Secondly, the revlog filtering PR embeds a FindCommitComponent in the view to be filtered. To avoid doing the same for all searchable components, the focused view should signal it supports search. The least-amount-of-code way I found for this was adding flags to a CommandInfo, and the Vec<CommandInfo> at the top gets checked for that. Alternatively it can also work by queuing a new InternalEvent, but that seems to require more and tighter focus/unfocus tracking that is currently being done.

@extrawurst Any comments on which implementation direction seems more acceptable? Personally I would favor the ECS approach, since at the end it would have the least code overall, be the most decoupled and testable, and also provide easy debugging (what action/message/event occurred, where from and to, and from which entity), but in the end search is useful irrespective of implementation.

[stale]

This issue has been automatically marked as stale because it has not had any activity half a year. It will be closed in 14 days if no further activity occurs. Thank you for your contributions.