path(s) to search should be part of command

[strait]

rg optionally takes one or more path arguments (file or directory) to search, positionally at the end of the command. Currently, this package is limited to the default behavior of rg, which is to search the current directory. (command is simply run in default-directory without any path as part of the command) The dir argument could be a path name or a list of path names when calling rg-run programatically. Even a single path as part of the command would be an improvement as it would allow shell expansion.

[dajva]

Thanks for the report. This package is based on compilation-mode which has some impact on the behavior.

1. I don't think shell expansion is done on the final command, at least globbing doesn't expand as I would expect it to. Did you try this and did it work for you?
2. Using a list of directories instead of a single one would have some impact on the user interface. Taking user input would mean a list of dirs which doesn't work well with completing-read. Or maybe it would work but it's unclear to me how this could be designed. Do you have ideas here?
3. Question is if you want use default-directory and specify subdirs to search or always specify absolute paths? Both is possible of course, but it has impact on the user interface (prompts) and readability of result.

I have not seen much need for this functionality in my own usage so I am a bit out of creativity when it comes to envision how this could work with the current implementation/behavior. Therefore I am also a bit reluctant to add it if it complicates the package too much.

Do you have ideas how this could be incorporated in the package? My thoughts here are mostly based on extending the current single dir concept with multiple dirs. Maybe it would be better to treat the rg executable command line dirs separately and have this as a fixed (as in non refineable from results buffer) value in a specific search function?

Note that it is possible today to specify the paths if you use universal-argument before invoking the rg function and then edit the final command line with multiple paths. This way of using the package is not well supported and a bit clunky but it should work. You will also miss out on a lot of features of the result buffer.

[strait]

Thanks for the comprehensive response.

I'm thinking of two situations where one would want a multipath search and the approaches to each.

1. Within a project consisting of 100+ dirs, the developer wants to narrow the search to 2 or 3 sister dirs. Perhaps the search term is a slot name that is very common in different parts of the project and the results from the entire project would be overwhelming.

   • From the top level search persective, a glob pattern would probably suffice, since sister dirs usually share some commonality in naming. Globbing is expanding for me within a compilation-start.

   • When searching from a buffer of a file that is within one of the sister dirs, a mechanism could be set up to include all the sister dirs in the path automatically. Provide a custom variable such as rg-path-group-regexs holding a potential list of regexs, each regex denoting a desired grouping of sister dirs. When searching from a file within a dir that matches a regex, the path list will become all dirs on that parent level which match the regex. When a user cares about having this feature, they will add their own regex to the initially empty list.

2. A user may want to search on selected dirs throughout the filesystem for whatever reason.

   • Interactively, this would probably need to be facilitated through something like using dired or helm to provide the list of path names.

   • Non-interactively, dir is checked for being a string or a sequence of strings.

Addressing your numbered points:

1. I've seen that globbing works when calling compilation-start, at least on Linux. I'm not sure how compilation-mode is supposed to work on Windows.

2. Interactively, it's probably best for a new command to provide multi-path search. Not sure yet on the implementation of prompting for a multipath value.

3. Continue using default-directory on single-path search. When dir is multi-path, perhaps change to parent or top level, for result readability. For multi-path the dirs would be expanded to absolute path before the command is run.

I'll try to come up with an implementation for this in the near future. Any other concerns?

[dajva]

I am still not convinced although you made some good arguments. I see the usefulness of this feature but I am not convinced it's common enough to motivate the added complexity in both implementation and user exposed concepts/interfaces.

The core of this package is doing quick interactive searches by using completing read or automatic extractions together with the "refine search" functionality of the result buffer. My main concern is that these basic features would be harder/convoluted with more special cases/states that impact how the package works.

This suggestion seems to have a risk to introduce such unwanted properties, using default-directory vs using command line, having some kind of multiple dir input reading vs single dir input reading, using absolute paths sometimes (which could be hard to read, especially in ungrouped mode) and relative sometimes.

This is my concerns, still. I actually think you have some good points and I am not entirey shutting the door for this. I mostly want to figure out if this is a path that I want to go with this package, how it would change the behavior and if the maintainance effort would be worth it.

To be a bit more clear about the possible paths this could go in:

1. Integrate "seamlessly" with the current functionality, essentially switching between 2 modes for the dir property of a search. That is as I understand it, your depicted path. It's need some delicate handling though to make sure the current properties of the package is not affected.
2. Add this as a side feature squeezed into the full command line search triggered by universal-argument. This would be pretty easy to implement. One could for instance add something to rg-define-search to expose the full command line for programmatic manipulation before submitting it to compilation-mode. This will not support refining from the result buffer though.

If you like to explore this and come up with a solution of this or some variation I am fine with it. I would accept an implementation of something like path 2 since it's less intrusive, but I can't guarantee an implementation of path 1 would be merged. It depends a lot of the details of the final solution.

[dajva]

No plans to implement this so closing.