-
Notifications
You must be signed in to change notification settings - Fork 37
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Searching through a set of files that are listed in a file. #130
Comments
This is not something that is currently not very well supported in this package. The main premise for this package are the three parameters, directory, query string and file-type/glob. Using full command line search means we can't modify the search parameters which cripples the result buffer. I know, the full command search is in there, just saying that this code path is not prioritized and is mostly there because of legacy compatibility with built-in grep package. |
Thanks for the considered reply. Happy to test if you incorporate something similar in the future. |
Hi,
thanks for the rg.el package. I'm trying to set it up so that I can search all my org-mode files that are stored in lots of different directories under my home directory. I have a workflow from the shell, which is:
Step 1: find the .org files
This takes a few seconds to search through my home directory, and so I would like to cache the results in a file:
(for context, there about nearly 1200 matches)
Step 2: search through that file list.
I can then use xargs to pass through the filenames (none of the filenames have spaces in them, else xargs -0 might be needed), and for example, here search for 'defun':
How best might I use rg.el to do similar, such that the rg buffer is more useful? Should I look into defining a new search? I have confirmed that if I do
C-u M-x rg
then add the xargs ... at the start of the command, it will work, but I'd rather not do that every time.note: there has been discussion, not yet implemented, about adding --files-from flag to rg for this case: BurntSushi/ripgrep#273
The text was updated successfully, but these errors were encountered: