Skip to content
New issue

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

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

rinari-find-* cache #33

Open
chalmagean opened this issue Jun 28, 2012 · 13 comments
Open

rinari-find-* cache #33

chalmagean opened this issue Jun 28, 2012 · 13 comments

Comments

@chalmagean
Copy link

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
Copy link
Collaborator

purcell commented Sep 1, 2012

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
Copy link
Author

a large project is around 2000 files

@purcell
Copy link
Collaborator

purcell commented Sep 2, 2012

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
Copy link
Author

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
Copy link
Collaborator

purcell commented Sep 3, 2012

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

@chalmagean
Copy link
Author

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

@purcell
Copy link
Collaborator

purcell commented Sep 4, 2012

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
Copy link
Author

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
Copy link
Collaborator

purcell commented Sep 4, 2012

Understandable. Just sharing tips.

@asok
Copy link

asok commented Oct 15, 2012

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
Copy link
Author

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
Copy link
Collaborator

purcell commented Mar 14, 2013

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

@chalmagean
Copy link
Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants