Took 0.40s wall time, so it only accounted for an insignificant fraction of the I confirmed this by running git ls-files a few times and found it only Unfortunately this didn't speed anything up. Generated once and then cached, avoiding the need to invoke git every Projectile-enable-caching will cause the git ls-files list to only be In, so git ignored files won't appear in the helm query. Helm-projectile-find-file only get a list of files that are actually checked This is done using git instead of just searching the filesystem to make Helm-projectile-find-file by invoking git ls-files every time it is invoked. The idea is that normally projectile generates the candidate list of files for Projectile caching: XXX: Don't actually do this! Was the projectile-enable-caching variable, which can be set to t to enable In my initial investigations to fix this the only thing I was able to find Responding to keystrokes if too many keypresses are typed blindly this way. ![]() Where sometimes the helm dialog will get out of sync and stop updating or Worse, there seems to be a race condition in helm in this situation, I would end up typing most of the file nameīlindly. Take helm several seconds to refresh after I typed the l, several more to If I was typing a file name like logging.h it would I'd hit SPC p f to find a file, and it would take 3-5 seconds to update the helm dialogĪfter every key stroke. Helm-projectile-find-file with fuzzy matching is very slow. Repository (containing well over 100k checked in files). ![]() This opens a fuzzy matching helm dialog that navigates the files in my currentĪ few months ago I started a new job where I'm working in a very large git Want to open a new file I type SPC p f to invoke helm-projectile-find-file. File completion using projectile as the backend.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |