Skip files confirmation?

[zonotope]

Hi. First of all, thanks a lot for this package.

Is there any way to skip the files confirmation in rg-project and just always go with the default type alias instead? Basically, I'm looking for something like rg-dwim, but that will still allow me to enter a search pattern instead of just always using the thing at point. Is that possible?

[zonotope]

I've opened #28 to add a new function for this.

[dajva]

Thanks for the report and the pr.

I am a bit reluctant to merge this, not because it's not a good addition but since there are a lot of similar additions that would make sense and could potentially cause an explosion of entry functions for rg.el.

The functions I have added so far are basic ones that I think make sense for all users but are not optimized for all usages. I actually miss some myself like quick search in current directory.

So, instead of adding a lot of entry functions with sligthly different behavior I would like an easy way to creating new entry points where the user can create the search defuns needed from a predefined set of behaviors, possibly with custom additions.

So something like this would be the thing you put into your init.el:

(rg-search my-custom-rg-search
  :dir 'project
  :files 'current)

This would create a defun called my-custom-rg-search that is using the project dir as search dir, current file type to filter the files and ask for a search string (triggered if :search is not supplied to the macro).

This is just a simple example of this feature. I would like to have predfined behavior as a choice but you could possibly supply custom functions for a lot of the customizations. This is essentially my idea of this feature. I have not really investigated this so it needs some ironing out before finalizing the interface etc. I would be happy to hear your opitions about it from a user perspective.

As for the suggested pr, I will hold it for now and see if my thoughts above will materialize into something useful.

[zonotope]

That's makes a lot of sense, and being able to succinctly define fine-grained custom searches would be really nice.

I thought about a more general configuration dsl for this before, but i thought it would involve too much of a refactor to be worth it initially. I don't think implementing a dsl like you describe would be too bad though. We can use a macro that leans on the existing rg-run function by first dispatching to helper functions that build the args for rg-run based on the config the user specifies, and the user would just get a prompt at the minibuffer as normal for anything they leave out of their config.

I might have some time to play around with this idea in that pr today or tomorrow, if you don't get to it first.

[zonotope]

I've added a macro to #28 to take in a search configuration and define a search function. I've also re-defined all the existing searches in terms of that macro and made sure the tests still pass. For example, the new definition of rg-project is

(rg-define-search rg-project
                  :dir project)

and the new search I wanted to add in the first place is

(rg-define-search rg-dwim-regexp
                  :files current
                  :dir project)

The possible keys and values are:

(:pattern (point literal regexp)
 :files current
 :dir (current project))

Strings can also be used for any of these values to indicate a static value (always do this search in "clojure" files, for example).

The docs need changing before this can be merged, and it might use a little cleaning up, but is this approach on the same track with what you were thinking of?

[dajva]

Thanks for the patch. I have not got time to review the details right now but just some notes about the general approach and interface.

1. In generat I think this looks good and in line with what I had in mind.
2. The :pattern config. This is merging the concept of extracting the pattern and how to interpret the pattern. My thought was to divide these to keep the interface more flexible. I admit automatic extraction of pattern would normally be literal and your approach makes the interface simpler. But making the more flexible interface would make extending the macro easier, allowing functions as values for the keys for instance.
3. We need doc strings for the defuns generated by the macro.

I will have time to review it more properly later this week but you can definitely go ahead and do the cleanup you were thinking of. Great work.