Request: Finer control over cache (like #404 but different)

[unphased]

Suppose we have a filesystem hierarchy like this:

~/project/branchA/ has a large number of files
~/project/branchB/ has a large number of slightly differently structured files
~/ has a small number of various files that are accessed often

CtrlP makes it super easy to set branchA and branchB as the root dir for cache, which works quite well.

But, sometimes I would like to search for stuff in say ~/ (Say I want to use CtrlP for looking up my dotfiles, and looking up files in my vim bundles folder, and stuff).

Due to the way it works, if I open vim in ~/ I am effectively unable to use CtrlP. This is simply because my project files are several gigabytes of hundreds of thousands of files: CtrlP when indexing ~ will recurse down into the project.

As it stands I could just leave it and let it finish indexing but this has many drawbacks. There is the duplication of the cache, which is not a huge deal (a few megabytes to store the paths of all files in the tree). But suppose I reorganize my dotfiles, now I have to wait 5 minutes to re-cache the entire tree again.

I don't know if there is a clear solution to this problem because it muddies the "refresh" function.

For reasonably sized workspaces CtrlP works fantastically.

I think it is perhaps not too hard to add an option (not enabled by default) that tries to be smart and substitutes in any existing cache files for a dir that it's about to scan.

We do not need to change any of the code which handles the lookup within the cache. We can just use the existing cache files to fill in our new cache, so this new (bigger cache of the entire tree) can be generated quite quickly because the majority of its parts are already generated.

In this situation, then, it will be possible (once caches are established on ~/project/branchA/ and ~/project/branchB/) to open vim at ~/, and then CtrlP would (1) not block for an extended time scanning both branchA and branchB, and (2) allow rescanning of non-project files on demand.

The reason why the option should be disabled by default is that in taking this shortcut the caches being generated may be pulling in stale data (file hierarchy and file names).

[kien]

A few problems I can see now:

1. Migrating/Invalidating the old cache files after changing the setting.
2. Appending the file's path when putting the parts together. E.g. subdir/file -> path/to/subdir/file.