Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Cache paths to disk #36

Closed
wants to merge 5 commits into
from

Conversation

Projects
None yet
3 participants

dtb commented Feb 24, 2012

This patch adds the ability to cache the directory listing to disk, so that the directory structure doesn't need to be traversed every time one opens vim and hits \t for the first time. See the related issue in the issue tracker

It could use a little cleanup still, but it's basically working, so I wanted to get some eyes on it, and see if anyone could test it out.

Here's what I still want to do with it:

  1. Move the caching functionality out of file_scanner.rb into its own class (this isn't totally necessarily, but is probably more maintainable)
  2. There's not currently a way to invoke @scanner.flush, which is what I use to force a rescan, rather than using the cache from disk. It would be best to fix this somehow, but I'm not sure what the best way to fix it.
  3. It wouldn't hurt to write a couple more spec tests.

I'm very open to feedback on the code and the functionality, and would be thrilled if people would try it out.

dtb added some commits Feb 14, 2012

New feature: cache directory index to disk
After scanning the directory, a file is written to disk which
serializes the array of files. When command-t is started next,
if this file is present, it is used instead of scanning the
files again.

dtb commented Feb 24, 2012

Just a note that if anyone wants to try this out, you can clone my repo, then checkout the cache-paths-to-disk branch. You'll need to go into your .vimrc and add the line: let g:CommandTCacheIndexToDisk=1

dtb commented Feb 29, 2012

The inability to flush a directory from within VIM due to this plugin is actually really a drag. Currently you have to exit Vim, rm ~/.command-t-cache, then go back into VIM. It really breaks the flow, plus it kills ALL of your cached directories, and not just the one you need to update.

lzap commented Jul 18, 2012

I like this, would it be possible also to expand this for tags? It's very slow on my projects.

dtb commented Jul 22, 2012

I'm not really sure how Command-T deals with tags. In theory, nothing is stopping this from working with tags (all it does is serialize the array of paths from ruby), but I'm not sure if it would actually be faster than reading the tags from your tags file.

Owner

wincent commented Aug 13, 2014

I'm going to close this (and sorry for not commenting earlier). I think the best way to deal with this for slow (ie. large) hierarchies at this point is to use the Watchman scanner.

If you're on an inherently slow filesystem (like an NFS mount) then there might still be a use case for this kind of thing, but I'd prefer to keep the core simple at this point and only reconsider that if there is significant demand for the feature.

@wincent wincent closed this Aug 13, 2014

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment