I'm looking for a way to quickly open files in my project's source tree. What I've been doing so far is adding files to the file-name-cache like so:
(file-cache-add-directory-recursively (concat project-root "some/sub/folder") ".*\\.\\(py\\)$")
after which I can use anything-for-files to access any file in the source tree with about 4 keystrokes.
Unfortunately, this solution started falling over today. I've added another folder to the cache and emacs has started running out of memory. What's weird is that this folder contains less than 25% of files I'm adding, and yet emacs memory use goes up from 20mb to 400mb on adding just this folder. The total number of files is around 2000, so this memory use seems very high. Presumably I'm abusing the file cache.
Anyway, what do other people do for this? I like this solution for its simplicity and speed; I've looked at some of the many, many project management packages for emacs and none of them really grabbed me...
Thanks in advance!
Simon
Testing here give me no problem with some 50000 file (well, I had to say that I had to wait some time, but Emacs only use 48 mB when it finished), You seem to have been hit by some bug you should probably report.
I'd suggest you take a look at this article. I have to support Trey's comment - I don't think your approach is very good at the moment.
Related
What I need
a fast/performant way to open any file under a large (git) repo (~9.8k files).
Context
I have tried various solutions, like Textmate.el and find-file-in-repository. I found these solutions via previous SO questions like this and this and through the LocateFilesAnywhere EmacsWiki.
While both solutions work wonderfully for small-to-mdeium repos, in this case they are practically unusable. When I start typing a filename, there's a delay of several seconds before I see any result. And changing any part of the search is very laggy too.
I think the main problem is that on typing any character, emacs/find-file-in-repository starts a shell command (git ls-files...). I really only need to do that when I have stopped typing.
Questions
is there a better library out there for this use-case?
if not, how can I introduce a delay into the command when I'm typing? i.e. while I'm in find-file-in-repository, I want the find-command to be invoked only when I stop typing (let's say a gap of 300ms).
Summary
After I received the three answers I tried them out (also answering my own question as none of the above solutions worked for me). I finally settled for helm-ls-git. Here's a comparison from my point-of-view:
Projectile
took around 30 minutes to index the repo. Since projectile is not aware of .gitignore, the actual number of files is more like 52k.
can be customized but something that just works (i.e. understands git) is preferable
may need to invalidate cache re-index time to time. That would be costly and frequent since new files are added everyday to the repo.
helm-cmd-t
looked good from the description and the source.
hard to install since it's not published in melpa/marmalade etc. More details in this issue I opened up.
GNU Global
Didn't try as it's likely to have the same problems as Projectile (git-unaware, needs it's own "index" that may need to be maintained time to time)
event-jr's answer however opened up some more options: I was unaware of helm till now. Looking at melpa for helm related plugins I found the following:
helm-git
This looked really promising
Was easy to install with package.el since it's in melpa
I also use and love magit - so this looked a good fit.
However, it kept failing with a magit-git-dir: symbol is void kind of error. Did not dive in too much but looks like it needs to be updated. Opened up an issue
helm-ls-git
As the readme says, this is magit independent.
Has been working wonderfully so far. Easy to install (melpa) and is fast.
I use GNU global for this. I have around 20K files in my project. You can run
M-x gtags-find-file and type first few characters. TAB will complete and show all the matching. You can type any characters which is part of the file name and press enter. Will show all the files that contains these characters.
I tried to use projectile for this. But it was way too slow for the 'project indexing'. It didn't complete the indexing even after 1.5 hours and I have to kill it!. Not sure some thing is wrong here. GNU global is much faster and finishes the entire tag creation within 15 min.
You can check out Projectile. It was basically created to provide something similar to C-p, but has a lot of extra project level features as well. First time project indexing will be fairly slow on such a big project, but afterwards Projectile will cache the project files (both on memory and on the hard drive) and subsequent projectile invocations should be nearly instantaneous.
Projectile also has a Helm plugin to display project files and buffers with Helm.
I use helm-cmd-t happily. It will cache the file list in memory. The cache controls are flexible enough for my needs.
I just answered your question about new repo address here:
https://stackoverflow.com/a/8025310/903943
It's https://github.com/lewang/helm-cmd-t
I've been using Eclipse without issue (I mean, besides the usual) for several weeks now. It's been speedy enough for my purposes. But as of today around noon, anytime I start typing an HTML tag or other autocomplete-able element, my whole System bogs down so much it's completely unusable. Watching in Task Manager, I show that Eclipse jumps from 0 up to 10-15% every time I type a "<" or ">" symbol!
I have a Core i7 PC with 6 GB of RAM, so this definitely isn't a system specs limitation. I've also uninstalled a couple of programs I installed today hoping maybe one of them was conflicting, but no dice. Even after a restart, I am unable to use Eclipse without pausing for several seconds every time it tries to auto-complete!
Anyone know what's going on here? I did some searching but all I found were VERY old bug reports that say the developers "are aware of the issue and are working on a solution".
First, I'd try bumping up the memory that eclipse has allocated to it:
-vmargs
-Xms2048m
-Xmx3072m
-XX:MaxPermSize 128m
That should be in your eclipse.ini file. This blog has some great reading as far as memory and Eclipse are concerned. Also you can read this lengthy SO thread if you need some more info and / or wish to induce sleep.
Next, try speeding up autocomplete. Go to Window / Preferences / Java / Editor / Content Assist / Auto-Activation and decrease Auto activation delay from 500 to zero.
Finally, you might look into hippie complete; the default key binding in Eclipse is 'alt-/' . This is also called "Word Completion" if you check out the shortcut list 'ctr-shft-l' ( that's L as in list ). On my mac the default key setting is 'ctr-.' . This is a faster version of autocomplete that I believe harkens back to the days of emacs. It seems to work great with local variables but not so great with functions on objects. Different beast I guess.
As a bonus, you can check here for a list of ways to speed up the Eclipse experience in general.
First, just as a test, try switching to a new workspace (File → Switch Workspace → Specify a folder which does not exist, it will be created).
If the problem is solved, this could be an issue with some bad settings or cache in your current workspace. If you can easily move to this new workspace (don't know how much effort you've put in customizing your workspace), I'd do that.
If you want to fix your current workspace, go into the .metadata/.plugins folder of your workspace, and look for folder that start with org.eclipse.wst. I'd try to take them out, and see if it helps (close Eclipse first). You may lose mostly history and cache in the process. You can check the folders specifically and intelligently guess what should stay.
If the problem is not solve by changing workspace, I would try downloading a fresh copy of Eclipse. You could try to reset the configuration folder, but that's a bit risky. If it's too much trouble, I'd start fresh.
From what I can tell from the docs, semantic works by slowly building up an idea of what's in your project by analysing each file (and possibly its neighbours) as you visit them. This is too slow. I'd like to just have it visit all the files in my project. Is there an easy way to do this? Having to visit hundreds of files before I can get decent autocomplete working seems crazy.
I've also got a etags file generated. Can I leverage that somehow?
Relevant info: Emacs on Windows, version 23.2.1
CEDET will automatically parse all files references via #include statements, thus providing pretty good completion. If you are looking to jump around in your files, you can setup CEDET to use GNU Global, CScope, to provide the database needed to move around a project by tag name.
In addition, CEDET will parse your headers and nearby files in idle time, so eventually you will have a complete database of all your local files in about 10 minutes after using the tools the first time. You can speed it up by opening a file, and calling
M-x semantic-debug-idle-work-function
which will go off and do that stuff without waiting.
In the end, I've found that the best solution is to brute-force the parsing of the files manually using a bit of elisp. The best answer I've found to this is here.
I am not sure if anybody has experienced this.
I am working with a very large file having 7000 lines of code.
I made a lot of changes and when i compared the file with the repository version, it showed me incorrect differences.
I guess the diff algorithm buffers only limited number of lines ahead/behind for searching the current line, and on failing to find that, it simply shows diff with current line in new file.
One such snapshot > http://picasaweb.google.com/lh/photo/ENwZ4gqXxiCF3SWqVnVAqA?feat=directlink
If anybody knows any workaround, please let me know.
Thanks
Easy workaround - use another diff tool. I'm serious. I wouldn't waste time splitting up my files, or wondering how to get it to work with Eclipse's diff tool if there's some known issue with really big files.
I recommend Beyond Compare 3. I say this having used many different diff tools. It's not free, but it's worth it. In the rare chance that it gets confused, it allows you to with a couple of clicks realign any areas that it got confused on. I have used it with some pretty large files, and it rocks.
If you're concerned about Eclipse integration, there's even a plugin, BeyondCVS, that allows you to launch your Beyond Compare diffing from the Eclipse right click 'Compare' menus. Its name is kind of misleading though, as it doesn't appear to be related to CVS.
If you need something free, try one of these diff tools instead:
WinMerge
SourceGear DiffMerge
What version of eclipse are you using? And what edition? (Java? CDT? ...)
Depending on those data, it could make a difference, since files with several thousand lines are known to be a problem for the diff algorithm.
See this thread for illustration.
And do check, as mentioned in the same thread, your error log to check if any particular message could help you to pinpoint the cause of the failed diff.
Compression process for one of my Applications build gets stuck and never finishes the
compression process (eternally stating "2.6 MB of 2.7 MB about 5 sec").
I couldn't find the solution by googling - even though I am not the first one to have this
issue.
Does any body know a fix to this issue?
I've never seen that before. What you could do is try another zip-tool. Maybe on another machine. Or delete some files from the problematic application directory, just to see which one is causing the trouble.
I have found the cause of the trouble-
I dragged the same file twice into the project -
now I have deleted one of the aliases and it zipped with the usual right click + compress.