search

dajva / rg.el

Emacs search tool based on ripgrep
https://rgel.readthedocs.io
GNU General Public License v3.0
474 stars 39 forks source link

More customizable rg-custom-type-aliases #35

Closed muirdm closed 6 years ago

muirdm commented 6 years ago

Thank you for this well thought out and useful-by-default package.

I wanted to hear your thoughts on a feature I had in mind:

Add mechanism to alter custom type aliases "dynamically", e.g. based on current file, current project etc. This would mainly useful with the DWIM command that selects type alias based on current file.

I have a big project and often times identifiers stretch across file types. For example, in UI code, identifiers are shared between template files and javascript files. In backend code, there might be one java package that references a bunch of names that are tied to XML files. I can achieve cross-searching using the existing rg-custom-type-aliases, but that will always give the the cross searching. If I searched for something in other, non-XML related java code, it would still search all XML files, which might give me results I don't care about. Similarly, if I'm ripgreping through backend node.js code, I probably don't want to also search handlebars files.

I propose allowing lambdas in rg-custom-type-aliases. This way I can make my lambda change type aliases based on the current buffer, current project, etc. rg-dwim would become (more) context aware, allowing for different grouped type aliases based on where you are searching from.

Of course if you don't care for this change, I can always implement it w/ advice around the dwim command, so don't worry about my feelings.

dajva commented 6 years ago

Sounds ok to me. If I understand you correctly you propose the value-type of rg-custom-type-aliases to be either a string (as now) or a lambda?

One could also put this one level higher to allow rg-custom-type-aliases to be either an alist (as now) or a lambda. This seems a bit more flexible and would also alow the user to prioritize matching of default alias (order of items in the returned alist) per project.

If you want to make a pr, please use the develop branch where the package has been split into multiple files.

muirmanders commented 6 years ago

My thought was to allow lambdas as elements of rg-custom-type-aliases rather than as the alist values. This seems more ergonomic. I like having it be a list so the user can insert many small lambdas, once for each custom type they want to define (as opposed to having only a single lambda). Also, having it be in the same list makes precedence with non-lambda custom types clear. Please look at #37.

dajva commented 6 years ago

Relate pr merged.