Disable searching for git/ignore files for path completion

[sigmaSd]

Currently helix uses default git/ignore searching options for file walker https://github.com/helix-editor/helix/blob/master/helix-term/src/ui/mod.rs#L484-L488

This searching for git/ignore files issues 14 syscalls total per directory instead of 3 without them
disable with

        .git_ignore(false)
        .git_exclude(false)
        .ignore(false)

As an example if a folder contains 287 files it issues 4110 syscalls instead of 926 , this in my testing with cold cache change the time from 15 second to 100 ms (in an old pc with hdd)

Also note that this searching is useless because we're already searching in depth ==1, so the only thing needed is the git/ignore files inside the current directory and not the sub-directories, (so 9 extra syscalls instead of 3186)

This is currently configurable in the file picker, but not i the path completer

What do I propose:

• make git/ignore also configurable in path completer (seems reasonable)
• change the defaults in file picker and path completer to not do this extra search by default (debatable)

Another idea is since the search is for depth 1 in case of completer, we can keep the same functionality while gaining all the performance, by disabling the git/ingore search, and manually filtering the git/ignore entries only in the current directory

[sigmaSd]

ref #6867 #6114 #5871

[pascalkuthe]

I am strongly opposed to changing the default for the file picker. Gitignore is a very useful feature and the overhead is negligebale since its a recursive crawl anyway. All the issues you linked regarding the file licker are unrelated

Something you left out here but mentioned on latex. This was a system with an old HDD and a cold cache. On a modern system the overhead is not very significant

[norcalli]

@pascalkuthe You're forgetting about NFS, which many of us have to use for work reasons and is definitely not negligible.

For me, every keystroke is slow and I checked via strace that it is in fact invoking this recursive search every time the path changes, not caching the information despite the path being appended to in 99% of cases, meaning that all of the ancestor git ignore information should probably still be valid.