Feature: Filter current branch list

[jwu910]

Consider adding a feature to filter results from each remote.

I was originally against the idea of needing to type in this tool. If users find a need for a filter results feature this can be considered.

When viewing the rendered list of branches/refs, bind key / to initiate a filter feature that lets the user type to filter by refs matching the characters in the query.

• list should update as user types
• first index of list should remain highlighted unless user navigates
• Should navigating left/right among remotes reset the filter, or should filter persist?

[drewbrokke]

bump. This would be super useful. I can live with just the arrow keys for navigation

[jwu910]

Will look into this! I have actually hit a few cases where it would have been really nice to have

[drewbrokke]

I would like to propose distinguishing between filtering and searching. If we followed the pattern set by less, the behavior would be as follows:

• When the user presses /, they are prompted for a search term. On submitting search, matches are highlighted, and they can jump from one result to the next by pressing n and N.
• When the user presses &, they are prompted for a filter term. On submitting the term, output is reduced to only show lines that match the filter term. Pressing & again and submitting a blank search returns output to normal.

This would be familiar to any users who are accustomed to the behavior of less (which is arguably the most commonly used pager afiak).

[jwu910]

This is really great feedback.

To clarify, would the workflow be something like / -> Type Ticket Number* -> Submit* -> n/N to navigate?

And from this search results view, the user can also press & to additionally filter the results by another text criteria?

[drewbrokke]

With how I imagine it, we wouldn't change views for search/filter, just adjust the current output (highlight terms, remove lines, etc.). Searching and filtering could happen independently of one another.

[drewbrokke]

But your workflow sounds right. Basically, n/N would always be bound to jump to the next/previous match, but if there is no search term then there are no matches, so they would be a no-op.

[jwu910]

would / and & open up all keyboard keys for typing prior to the submission of the query?

[drewbrokke]

Correct, it should focus an input which will grab all keyboard input, so you can type "q" and such :)

[drewbrokke]

Basically I'd want to be able to search and filter in a way similar to how I could if I just called git branch on the terminal.

[jwu910]

Right on, I had the same thing in mind then. Similar to the search/find in Vim I guess.