Support filtering on some views with '/'

[jesseduffield]

• PR Description

This PR adds view filtering to all list/tree views excluding the commits view. When you hit '/' on one of these views it brings up a prompt that allows you to filter down the contents of the current view based on what you type.

Filtering is distinct from searching, which we still use in the commits view and staging view. When searching, the contents of the view aren't filtered but matches are shown and you can iterate through them.

Searching makes more sense than filtering in the staging view where you still want to see the surrounding context. With the commits view, you can make the same argument but I can also see reason to support filtering there too. I don't really want to add a separate keybinding for that unless there's a strong need for it.

This PR does not introduce filtering for file views because it's enough work to warrant its own PR. I've got a commit here which adds filtering and then replaces it with searching and I'm keeping that in the git history so that it's easier to go back to filtering in the follow-up PR.

TODO:

• consider ways to make searching and filtering more similar (currently we filter in real-time as you type, but when searching we only apply the search after you hit enter)

• Support filtering in file views.

• Please check if the PR fulfills these requirements

• Cheatsheets are up-to-date (run go run scripts/cheatsheet/main.go generate)
• Code has been formatted (see here)
• Tests have been added/updated (see here for the integration test guide)
• Text is internationalised (see here)
• Docs (specifically docs/Config.md) have been updated if necessary
• You've read through your own file changes for silly mistakes etc

[github-actions]

Uffizzi Ephemeral Environment deployment-26821

☁️ https://app.uffizzi.com/github.com/jesseduffield/lazygit/pull/2680

📄 View Application Logs etc.

What is Uffizzi? Learn more!

[stefanhaller]

Oh nice! I'm on the go right now, but looking forward to trying it out tonight when I get home.

[stefanhaller]

This is great, for branches I like this much better than searching.

I didn't look at the code at all yet, so can't comment on that. A few observations on the behavior:

• When hitting enter on a branch to see its commits, filtering is canceled. I would find it desirable to restore the filtered view when escaping back out from the commits view. Use case: you are looking for a certain branch, can't quite remember which one it was, filter the list down to a few likely candidates, enter one to look at its commits, no it wasn't the right one, back to the list; argh, the filter is gone.
• When escaping from the filter, it retains the same selection index. It would be nicer if the selected entry would stay selected. (It might help a bit with the previous problem.)
• When scrolling the unfiltered list down, then starting to filter so that there are fewer filtered items than fit on the screen, the list doesn't scroll to the top, so you don't see them all. This is confusing, it looks like there are fewer filtered entries than really exist.
• For filtering files, it looks like the filter is applied to the entire file path. I find this a bit unexpected, I'd expect to filter on the file name only. I'm not totally sure though, happy to discuss.

[jesseduffield]

I would find it desirable to restore the filtered view when escaping back out from the commits view

Agreed. I'll make it so that it only cancels the filter if the context is deactivated and it's no longer on the stack. I do think it's good to cancel it after it's no longer on the stack because otherwise you might forget you had filtered the view after you leave and come back.

When escaping from the filter, it retains the same selection index. It would be nicer if the selected entry would stay selected.

Hmm I think this should be doable: I just need to keep track of the unfiltered index that's selected

When scrolling the unfiltered list down, then starting to filter so that there are fewer filtered items than fit on the screen, the list doesn't scroll to the top, so you don't see them all.

I'm thinking that when filtering we should just always scroll to the top

For filtering files, it looks like the filter is applied to the entire file path. I find this a bit unexpected

It's currently done this way just because it's easy to implement: I can filter the original list of files and then pass that to the function that builds the tree. It also helps because when switching from tree view to flat view the filtering doesn't need to be re-applied. I think some users would appreciate the behaviour: if I have multiple files with the same name (e.g. mod.rs in a rust project) it's useful to be able to include the folder name to disambiguate. I'm thinking of leaving this as-is and getting more feedback before changing it (partly due to my own laziness)

[jesseduffield]

Also I intend on refactoring this code quite a bit before merging so don't worry too much about how it's currently structured

[mark2185]

Regarding the idea behind the PR - yes please.

I don't really want to add a separate keybinding for that unless there's a strong need for it.

How about a separate keybinding to toggle the functionality when something is being searched/filtered? I.e. pressing e.g. ctrl+R switches the search to filter and updates the view.

That way we don't have to have separate keybindings for each functionality, nor do we have to decide which panel is gonna use what.

[jesseduffield]

I'm open to that but there's an additional problem in that with commits we currently have code depending on the ordering and we'd need to do an audit to see what breaks when we actually allow filtering. I also fear that things will get really slow trying to filter the commits vs search them, but for all I know it's similarly expensive to searching

[stefanhaller]

For commits there's the additional problem that we have another concept of filtering already (ctrl-s). It could be confusing to add the / filter on top of that.

[stefanhaller]

Was just briefly testing the latest version, great work!

One thing I noticed: when you enter a remote and filter on its branches, there's no way to exit filter mode. Takes you back to the list of remotes instead of cancelling the filter.

[jesseduffield]

@stefanhaller good pickup. I've pushed a fix for the remote branches issue just now.

I've still got some things to go before this PR is mergeable:

• ensuring actions on directories work as expected while filtering
• i18n'ing text
• differentiating between filtering commits by file vs by text
• refactoring

[jesseduffield]

No longer globally true so I'm removing it

[jesseduffield]

I've updated some of the wording so that it's clear when you're filtering by text vs filtering file status and filtering commits by path.

[jesseduffield]

@stefanhaller did you have any thought on this PR before I merge?

[stefanhaller]

I have been running with this locally for a while now, and I love it, it's such a great improvement.

I didn't look at the code very much, most of the changes are in areas that I'm not very familiar with. Just to small things below.

[stefanhaller]

What about this? Is it something important?

[jesseduffield]

Addressed in 3d2e548

[stefanhaller]

Typo:

Suggested change

	We intend to support filtering for the files view soon, but at the moment it uses filtering. We intend to continue using search for the commits view because you typically care about the commits that come before/after a matching commit.
	We intend to support filtering for the files view soon, but at the moment it uses searching. We intend to continue using search for the commits view because you typically care about the commits that come before/after a matching commit.

[jesseduffield]

Good pickup, fixed