3 ms·
I agree your replies are weird. Ignore files would be nice if you wanted repo specific filters or even user wide global filters. But for on-demand filters at se
by burntsushi 6y ago
I agree your replies are weird. Ignore files would be nice if you wanted repo specific filters or even user wide global filters. But for on-demand filters at search time, the frontend could add a feature for it and implement it with the `-g/--glob` flag.
- the_mitsuhiko 6y agoSo I guess since I started this entire thread here is why it even came up: datasette (a tool I use) is something you run locally. In particular this plugin also is pointed at a local checkout of the repositories you're working with. So for instance in my case I have all the code I work with in ~/Development. Since I also use ripgrep for local development I typically include .ignore/.rgignore files to control what I'm searching around in my repos. Doing "excludes"/"includes" across a variety of repositories is hard at query time because they layouts of those repositories can be very different. For instance in some JS repos you do want to search in "dist" whereas in others you don't because "dist" gets generated out of "src" for instance and just ends up being a duplicate etc.
- burntsushi 6y agoAh I see. I didn't know what datasette was. The way I see doing includes/excludes at query time is this. You run a search without excludes for example. You see a bunch of stuff coming back all in one directory that you don't want for this particular search. So you add an exclude rule for that directory. And then just refine results that way. If you have a bunch of similarly named directories, then I think that just means that the exclude rules at query time need to be more specific. e.g., use the full path to the directory. I think the feature being requested here is an interactive feature of the user interface, where as ignore files are more like a static fact of a directory tree.