Open YellowOnion opened 2 years ago
Update: I just ran another proflie after it got really laggy:
https://gist.github.com/YellowOnion/a07e1b81fec89bb5d7e910a8756b014c
:wave: I'm also getting the same error, with it getting slower over time as well.
Edit: Seems to apply for other languages with lsp such as python with pyright, again downgrading to emacs 28 just fixes it.
I'm running emacs 29.0.5 with pgtk + native comp (Note: downgrading fixes the error).
And flycheck doesn't display diagnostics.
Error running timer ‘lsp--on-idle’: (doom-hook-error lsp-on-idle-hook lsp-diagnostics--flycheck-buffer (error "Two bases given in one event"))
Repeats constantly in the messages when flycheck tries to show diagnostics,
Have the same problem with Haskell LSP. NixOS, Emacs 29 pgtk+native comp. Plenty of "Two bases given in one event".
I moved to gccEmacs i.e. v28 and still getting issues with c coding now.
I'm extremely close to giving up on emacs, I feel like i'm wrangling with layers and layers of crap, and projects like spacemacs and doom macs are trying to fix issues but they also hide issues and make it so hard to debug, you find a guide on profiling emacs, but they specify all the controls in normal vanila emacs, and even doom emacs seems to tell you on occasion to use ctrl+X instead of the evil equivalent.
With that being said I've FINALLY figured out how to interact with the profiler:
And guess what is causing the issues! evil mode.
Wow, any theories why?
Same here. I need to restart Emacs each time this issues arises.
❯ .emacs.d/bin/doom version
> Executing 'doom version' with Emacs 29.0.50 at 2022-01-30 13:30:56
GNU Emacs v29.0.50 2ab73286b7a58eb983da21bca8b781ec884eb996
Doom core v3.0.0-alpha HEAD -> master 9cfd7980 2022-01-30 02:42:54 +0100
Doom modules v21.12.0-alpha HEAD -> master 9cfd7980 2022-01-30 02:42:54 +0100
~
❯ sfetch
OS: Debian GNU/Linux 11 (bullseye)
Kernel: Linux 5.10.0-10-amd64
CPU: Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz
Memory: 3923516 kB
Emacs version: GNU Emacs 29.0.50 (build 4, x86_64-pc-linux-gnu, GTK+ Version 3.24.24, cairo version 1.16.0) of 2022-01-06
~
❯ rust-analyzer --version
rust-analyzer 183ef048f 2021-11-22 stable
I know it's tempting to use an unstable emacs version to get the latest performance improvements, but you should just switch to a stable version after you reported an annoying bug like this https://www.gnu.org/software/emacs/history.html. I also know many of you use arch(so do I) but in terms of emacs it's not the best solution to use a rolling release distro, unless you want to find and fix bugs.
I still see this quite a bit with stable 29.1.
It is reliably triggered (or at least exacerbated) for me if I split the buffer on the same file, and have two different views of the same file at once.
Closing one of the views does not fix the issue, only an emacs restart does.
Weirdly, opening rustic-popup seems to speed it back up again.
It's not related to lsp, as I see the same problem if I disable that - seems to be rustic
itself.
What did you expect to happen?
Performance is consistent.
What actually happened?
Performance degrades over time, I suspect related to the act of editing the file.
Performance gets better if I leave it for 10 mins idling.
Emacs process is pinned at 100% for a few seconds when it gets really bad, so it's not
rls
latency or anything like that.There's a bunch of errors:
https://gist.github.com/YellowOnion/f648cb458ad0127b04e6049631d64456
Describe your attempts to resolve the issue
I tried profiling but not sure how to expand the results in evil mode.
LSP mode is disabled in
init.el
but it's still running which is probably causing more issues (clashes between racer and rls?)Steps to reproduce
Edit rust file for 10 mins or so.
System Information
https://gist.github.com/YellowOnion/f648cb458ad0127b04e6049631d64456