eschulte / rinari

Rinari Is Not A Rails IDE (it is an Emacs minor mode for Rails)
http://rinari.rubyforge.org
GNU General Public License v3.0
413 stars 68 forks source link

rinari-find-* cache #33

Open chalmagean opened 12 years ago

chalmagean commented 12 years ago

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 ?

purcell commented 12 years ago

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

chalmagean commented 12 years ago

a large project is around 2000 files

purcell commented 12 years ago

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.

chalmagean commented 12 years ago

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.

purcell commented 12 years ago

As the saying goes, the hard thing to figure out would be when to invalidate the cache.

chalmagean commented 12 years ago

That's not hard at all, manually would be just fine (or on each session). That's how CTRLP works (in vim).

purcell commented 12 years ago

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.

chalmagean commented 12 years ago

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.

purcell commented 12 years ago

Understandable. Just sharing tips.

asok commented 12 years ago

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.

chalmagean commented 11 years ago

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).

purcell commented 11 years ago

Given enough time, I might well look into replacing the jump code with a dependency on projectile.

chalmagean commented 11 years ago

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.