Feature request: search file names

[dajva]

Feature request: search file names

[dajva]

I have been thinking about adding this but it's quite far down on my priority list. Also find-dired works well enough for my use cases so the motivation for implementing this is pretty low.

Anyway, I'll keep this open for now since it would be a nice addition.

[seagle0128]

Agree. It's low priority.

For me, find-dired doesn't work well as expected, especially on Windows. Painful!
I have to use find-lisp-find-dired instead.

Thanks for adding to your backlog.

[muirdm]

If you are using ivy/counsel for example, you can do (setq counsel-git-cmd "rg --files") and then you can use counsel-git to get a searchable/filterable list of all files in your project. I think you can do similar customizations for other searchy packages (e.g. projectile) for similar results.

Is it out of scope of this package to provide rg integrations w/ other packages as above w/ counsel?

[seagle0128]

Thanks, @muirrn .
I am using counsel-fzf to find the files in the directory. Also, this feature is nice-to-have one. Maybe it's a option or parameter in the rg interface?

[dajva]

@muirrn: I am not sure I understand what you are proposing here. I am not using counsel myself so that might be the reason.
Do you want to have custom ways to list files to be searched by rg, not only based on directory or project as is currently available?
Or is your suggestion related use this package for listing files that will be supplied to other packages.

[muirdm]

I was wondering if rg.el could include "glue" configuration that makes other packages (e.g. counsel) use rg instead of find or git or whatever they currently use. I don't think it really makes sense, so I retract my idea.

[seagle0128]

@dajva In *rg* buffer, there are many options to choose for searching the keyword. Is it possible to add the "list files" option there? That's just my thoughts. counsel-fzf is good enough for me anyway.
I am fine to close it if you think it doesn't worth to implement it.

[dajva]

@seagle0128: I don't think I will be implementing this (in the forseeable future). I have kept this open since I don't reject this suggestion and would accept a pr for this in one way or the other. On my part, we can keep this open since the number of stale issues is low in this project.

[slippycheeze]

FWIW, I'd suggest y'all investigate the fd tool support in Emacs, which brings a comparable sort of solution to the find-dired space.

[ylluminarious]

Looks like there is such a package for fd here. Personally, I like find just fine and I also like bfs.

[seagle0128]

@ylluminarious fd is fast, but slower than rg in my testing. Another reason is I don't like install many similar tools personally. Anyway fd is another option here.

[ylluminarious]

@seagle0128 Thanks for the observation. I was curious whether rg would be faster than fd for me as well, so I did a little bit of my own testing.

I searched in a big directory which contains many documents that are named with a certain word, so that's the test corpus. As far as I can tell, each utility produced the same output (i.e., found the same files) so the only difference is speed.

I used time to benchmark the commands. Here was what I found:

find . -iname "*word*"          1.31s user 13.30s system 73% cpu 19.796 total
rg --iglob "*word*" --files .   7.88s user 109.74s system 928% cpu 12.665 total
fd -HIi ".*word.*" .            4.89s user 61.79s system 1101% cpu 6.054 total

rg was about 1.5x faster than find, but fd was about 3x faster than find or 2x faster than rg. So fd does seem to be the winner in terms of speed on my system, but perhaps this varies depending on CPU since fd is clearly taking huge advantage of multiple cores.

[dajva]

No plans to incorporate this in the package so closing.