Lf: Feature request: filtering

[AvianY]

Would it be possible to create a filtering feature?
meaning that one could type in a command like filter word and only the files and dirs which
include the "word" would be shown. I don't know go, that's why I would like to ask if this would be hard to implement and if you could consider it :) ?

[gokcehan]

@AvianY filter has been mentioned to me a few times before but I don't think we had an issue for this yet so thanks for creating this issue. I guess this is a much requested feature so we will probably add it at some point though I don't know when. I don't think this will be difficult to implement so if anyone wants to tackle on this, let me know and I can give some directions.

[AvianY]

This could be used in more than one way.
Beside the obvious filtering to see only the relevant files in a folder, there is one more:
You can implement a "travel" mode, where the contents get filtered down to a single folder upon which the folder is selected and you can repeat the process in that subfolder. This is very fast and efficient way to drill down directories.

[gokcehan]

@AvianY That "travel" mode, is that something implemented in ranger? To be honest, I had never used filter in ranger until people mention it to me and I'm still not sure how people make use of it. It would be nice if people can give me some ideas about use cases. We have something similar for the "travel" mode you describe as searching with incsearch option and find commands with findlen and anchorfind options. It may not be a good idea yet to implement a third feature for similar purposes. I guess also maybe that feature may be implemented easier as an option for searching rather than being part of filter. Maybe something like filtersearch option which when enabled makes it only show files matching the search pattern, although I'm not sure yet if this is a good idea or not.

[ngenisis]

The nnn file manager has a navigate-as-you-type that sounds like what @AvianY is calling "travel" mode, which would be a killer feature for lf.

[shabahengam]

fff has a great filtering mode and the project is written in Go.
@gokcehan please check that project if you have time.thanks

[wisp3rwind]

It would be nice if people can give me some ideas about use cases.

One very powerful combination of commands I find myself using in ranger is :flat and :filter: First flatten the tree, then only select certain files at lower levels in the tree using filter, and apply some action to them, such as moving/copying/deleting (the sparse subtree only!), :bulkrename, etc. These operations might otherwise require some shell code using loops or elaborate find/rsync file selection. For one-off operations, I'd usually prefer an interactive approach. (Note that ranger quickly becomes unresponsive as a result of :flattening trees with too many files, which easily renders this workflow unusable)

[wpcarro]

@wisp3rwind I too think :flat from ranger is essential -- especially when composed with :filter. I'd love a way to search for files in subdirectories from within lf. Currently I use fd in another terminal, but this breaks my context since I leave lf temporarily.

Perhaps it's worth making another issue to track the support for :flatten or a similarly named command. Or perhaps it's worth leaving it here since it is a nice companion to the :filter command.

I'd be happy to contribute, but alas, I no virtually no Go. I could give either command a change, but I would need some pretty serious hand-holding.

[wpcarro]

One thing I should note, is that I wish ranger's :flat command didn't require any arguments. If it defaulted to an entire tree flattening, that would be even more useful imo.

[wisp3rwind]

Perhaps it's worth making another issue to track the support for :flatten or a similarly named command. Or perhaps it's worth leaving it here since it is a nice companion to the :filter command.

Yes, certainly this is a separate feature. I just mentioned it here to illustrate my uses of :filter. I'll open an issue for it.

I'd be happy to contribute, but alas, I no virtually no Go. I could give either command a change, but I would need some pretty serious hand-holding.

Same here, I won't have the time in the next few months, though...

One thing I should note, is that I wish ranger's :flat command didn't require any arguments. If it defaulted to an entire tree flattening, that would be even more useful imo.

Maybe the default could rather be flattening one more level? I.e. :flat could in general support arguments :flat [+|-]<n> and with the default :flat +1. Flattening out entire trees is a potentially very heavy operation (and I guess it's easy to underestimate the depth of a tree), and if bound to a single key, executing multiple :flat +1 could be almost as fast. I don't use :flat in ranger sufficiently often to really judge what would be best, though.

[wpcarro]

@wisp3rwind those defaults seem reasonable. I couldn't find anything like :flat * where it would flatten everything, and I think a feature like that would be important.

Also, nit, but :flatten feels like a better verb than :flat to me, so I think if lf implemented something like this, :flatten would be a better name choice.