-
Notifications
You must be signed in to change notification settings - Fork 48
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
`racer-eldoc' make type slow #86
Comments
I'm afraid I'm going to need more details to investigate this. Can you give an example where racer-eldoc is too slow? |
Oh, I'm sorry that forgot to mention the environment, I'm on windows 8 64, compiled racer using nightly-msvc(release version). And I'm using auto-complete for completion. |
Aha, Windows! Starting processes on Windows is slow in Emacs. We really need to start a persistent racer process to make racer.el faster. In the meantime, perhaps just disable eldoc? We could consider not enabling it for Windows users by default. |
I'm experiencing the same problem on Arch/Linux. Evaluating |
Would you mind running |
I have a project, where I can deterministically reproduce two cases, in which calling |
For what its worth I'm still encountering this issue. Everything was fine for a while but as my project got larger the slow down got nearly unbearable. To test I find that moving the cursor over variables in the scene file of https://github.com/Kethku/RustyRayTracer causes a multiple second delay. This makes rust in emacs unsable. |
Experiencing the same thing, any updates? It seems like it is happening even when I'm not typing, whenever I have racer-mode enabled, even if I am just moving around in the file, occasionally racer will start up and my entire emacs comes to a halt and never seems to finish. I noticed that in Task Manager a new subprocess was being added to my emacs called 'racer', and a corresponding 'Console Window Host'. When I close the 'racer' process emacs starts working again (and it closes the console window host process). This is what it looks like: I am using spacemacs-base with only a few layers, but I was seeing a similar thing when doing a custom emacs configuration. I am on Windows 10 Pro. It does seem eldoc related, mostly because racer just doesn't do anything otherwise, if I disable eldoc mode but run the racer-find-definition command the same thing happens. For reference, in case it is useful, this is the output I got from racer-debug after closing the racer subprocess in the task manager.
|
Also, I just checked, and apparently when I'm hovering over something in the current file or in the std library and do racer-find-definition it works fine and very quickly, but if it is over a symbol it doesn't know about it keeps looking for it and doesn't give back my session. And so I think eldoc is just having it check racer all the time, and so it consistently fails to find definitions for things. |
Hmm... |
That might be a good way to go. I decided to just disable global eldoc mode which has mostly solved things. I also tried running the commands that were hanging individually on eshell with RUST_LOG=debug and I think my main problem is that I am using winapi. Just trying to look for one of the things I imported it started looking through tons and tons of stuff, so although it seemed like it was hanging, I think it was just taking forever searching. So I don't know if there is a great approach for this, ideally it just wouldn't be a blocking operation, but given that it currently is, I don't think I will be able to leave eldoc enabled at all. |
It's terrible... |
Yeah, I recently moved off of spacemacs to a custom config, assuming that the slowness I was experiencing was due to throwing so much different stuff together in a bit of a kitchen sink. At least now I have insight about what configuration changes make my emacs go from responsive to super laggy. Unfortunately, it seems like I run into a lot of the same slowness with vanilla racer-mode + company-mode, even with a fairly small project. This is not just for racer mode, I've also encountered things like this for most of the haskell integrations as well. It seems like having emacs start processes synchronously all the time when you move your cursor or type is not a very good way to have a responsive editor. |
I can confirm that this is a problem for me for any medium-to-large-sized Rust buffer. It makes editing Rust code very unpleasant. I'm on OSX with an SSD and a recent Emacs. |
I ran into this tonight, but managed to fix it using eldoc settings. Eldoc already has a way to do idle timing.
This means eldoc won't start trying to render until half a second after your last input. You can increase this if that's still causing jank for you, or decrease it if you want it to show up after and the process spin-up doesn't take as long. I've found that going down to 0.2 still works ok for me. You could also just lambda this into the racer-mode-hook if you wanted, the way I do it above with the discrete function is just personal preference. |
I use
profiler-start' and
profiler-report' to find the eldoc make typing slow. I disabled eldoc by(setq eldoc-documentation-function nil)
The text was updated successfully, but these errors were encountered: