rinari
rinari copied to clipboard
eschulte
rinari-find-* cache
I am working on a few large projects and doing rinari-find- on almost anything (rspec, controller, etc) takes a very long time. Is there a caching option hidden somewhere ?
There's no caching option, and I can't immediately see how a reliable caching mechanism could be added. How large are the projects? And are you on a platform with a very slow disk or filesystem (e.g. Windows)?
-Steve
Yeah, that's a few files. This is probably an issue for the jump.el project, which rinari uses. I believe it first finds all files in the project dir, then filters them according to the jump rules, so perhaps it can be modified to only search certain directories.
I don't really mind the initial find, it's just that I would expect a caching mechanism to be in place so I don't have to wait each time I do a search. I'll take a look at jump.el, maybe I can figure out something.
As the saying goes, the hard thing to figure out would be when to invalidate the cache.
That's not hard at all, manually would be just fine (or on each session). That's how CTRLP works (in vim).
Well, I mean it's very hard if you want to make it work correctly without manual intervention.
An intermediate step would be caching everything but invalidating the cache when creating / editing / deleting files from within Emacs.
BTW, if you have Emacs 24, you can enable recentf with a very high value for recentf-max-saved-items, say 4000. Then, if you enable ido-use-virtual-buffers, you can just use ido's buffer switching to switch back to previously-visited buffers by name, even if they are no longer open. I habitually use this technique, because it works in non-rinari projects too.
I need my find to be specific to the current rails project and not have any file I've edited as a result since I constantly switch projects, open gems, edit emacs files etc. So I need a precise jump, and a fast one.
There's a projectile which has got file caching mechanism. Rinari would have to depend on it. It's easy to get files from subdirectories of the project root and invalidate cache. Just adding my 3 cents to the discussion.
I've tested projectile and it works pretty well. It also has relative paths on the file names which makes it pretty readable (if you have ido separate matches on separate lines).
Given enough time, I might well look into replacing the jump code with a dependency on projectile.
I think that's a step in the right direction given the fact that projectile is actively maintained and it's author is very responsive.