[vim/vim] set pathignore+= feature like wildignore but to prevent the find at all in some directories (Issue #12482)
Lucas Grigolon Varela
It would be good to have the option to define some paths like node_modules to be ignored from the :find at all. So the feature would be used and configured similar to the wildignore but to prevent :find of happening inside some directories to increase the search speed when using a path like path=.,**,,
The idea is to improve the experience while using the find command, making possible to have a 'global find' in the whole project directory.
Example: set pathignore+=/node_modules/,*/pycache/
Describe alternatives you've considered
Not using the :find with path=.,**,, but instead using something like path=.,, based on the gist https://gist.github.com/romainl/7e2b425a1706cd85f04a0bd8b3898805
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Peter Benjamin
According to @romainl from the linked gist above:
&wildignoreis only applied after the search, to build the list of candidate for:help 'wildmenu',
it is only used for thewildmenuso it is only used for the:findfamily of commands.
The suggestion for 'pathignore' would be to prevent Vim from having to execute searches in given paths.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
monkoose
Yes I know this. 'wildignore' works only for completion menu as romainl described in his gist and thats why it take the same amount of time to do actual search.. I just asked is there a reason to have new option with the same content (or can it be different)?
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Peter Benjamin
Apologies. I misunderstood your question.
I cannot think of a scenario where it is desirable to have a separate option to control where :find does the search.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Lucas Grigolon Varela
If using the same option for both won't break any existing user workflow I can't see the benefit of having two options for it.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Romain Lafourcade
FWIW, I find the whitelisting approach detailed in the linked gist both elegant (this is rare in Vimland) and effective, so I don't think this would be needed.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Bram Moolenaar
> FWIW, I find the whitelisting approach detailed in the linked gist
> both elegant (this is rare in Vimland) and effective, so I don't think
> this would be needed.
It appears the remaining issue is performance. Currently when
'wildignore' contains something like "*/.git/*" then all files in and
below a ".git" directory will be discarded. But the search in this
directory still happens, and can take quite a bit of time.
Without changing the options, the implementation could check for
encountering a directory which will have all matches discarded by
'wildignore' and do not scan that directory. This needs to be done
carefully. And avoiding expanding matches into a full path and
compiling the patterns in 'wildignore' when no match is possible,
otherwise we make other cases slower.
--
Contrary to popular belief, Unix is user friendly.
It just happens to be selective about who it makes friends with.
-- Dave Parnas
/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
/// \\\
\\\ sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
C.D. MacEachern
Maybe a findprg option like grepprg might be possible? That way you could set it to something like rg --files or fd which are both fast and can respect gitignore files, so you wouldn't need to manage some ignore option in Vim.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Romain Lafourcade
@craigmac I proposed that idea, and more generally to provide a *prg counterpart to every *expr option that didn't have one and vice-versa, back when @brammool was fishing for ideas. It was ignored at the time but I still think it would be great.
My two favorites would be findprg (as well as the corresponding findexpr) and includeprg.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
monkoose
Maybe a
findprgoption likegrepprgmight be possible?
Yes, this would be much better.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Lucas Grigolon Varela
Not proposing against it, just adding some context:
I like the approach of findprg the only downside is the necessity to use a external tool - which may be good because of the Unix philosophy to do one thing and do it well and the focus of vim is not to be a "find file" program - but the original suggestion would improve vim without needing to have anything else installed alongside vim - I know find command is available on almost all Unix systems.
The whitelist approach only work until certain point, when you have to work with dozens of differentes code bases, different programming languages (in the context of SRE/DevOps we go from C to Ruby, Go, Rust, Helm, Yaml, Json, JS, TS, Java and so on) and some big projects with lots of folders inside folders then it become a mess to create this whitelist for everything and the strategy to "ignore" (both for find and for the wildmenu) start to become more interesting and more ergonomic.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Bram Moolenaar
My response only appeared on the maillist:
Right, using 'wildignore' for this should just work.
It appears the remaining issue is performance. Currently when
'wildignore' contains something like "/.git/" then all files in and
below a ".git" directory will be discarded. But the search in this
directory still happens, and can take quite a bit of time.
Without changing the options, the implementation could check for
encountering a directory which will have all matches discarded by
'wildignore' and do not scan that directory. This needs to be done
carefully. And avoiding expanding matches into a full path and
compiling the patterns in 'wildignore' when no match is possible,
otherwise we make other cases slower.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Lucas Grigolon Varela
@brammool That would work and seems to be the best approach to be honest.
I just suggested a new option because I was not sure if the underlying code implementation and behaviour of wildignore should be changed or not.
Thank you for your insights.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.