Hacker News Reader

Comment by jpe90 | Hacker News Reader

I really want to use Emacs but I can't get Company + any LSP to come close to vs code or coc.nvim. When I configure company to trigger instantly on a single keystroke, Emacs completely locks up pretty much every time I hit a key.

View on HN

> When I configure company to trigger instantly on a single keystroke, Emacs completely locks up pretty much every time I hit a key.

Emacs using an elisp JSON parser is about 15x slower (!) than using a native JSON parsing lib. It's borderline criminal (just kidding): I think LSP should simply test if native JSON parsing is avail and refuse to run if it isn't.

I'm using LSP-mode and it flies (AMD 3700X / 32 GB of RAM / Emacs native compilation branch / native JSON parsing).

Apparently LSP-bridge is even faster so I may try it but if "Emacs completely locks up" when you hit a key due to lsp-mode, there's an issue (and a solution).

I'm also on an AMD 3700X, 32G of RAM, with Emacs native compilation branch. I'm totally unaware of elisp vs native JSON parsing though, I was just using stock Eglot that came bundled with Emacs.

It's more a question of where you got your Emacs. Native compilation, native JSON parsing, and a bunch of other things are configure-time options.

Oh I see, I build from source but I’ve been using the same configure options forever (just native comp and rename the ctags binary). I’ll look them over again.

Check that you have `libjansson-dev` installed, or whatever is the equivalent on your system.

Looks like I’ve got that on my machine, and I built Emacs —with-json this time. Performance is still better but it’s still stuttery.

I guess it’s related to either the json parsing happening on the main thread and/or the LSP servers using company-capf which I think is a synchronous backend?

It seems like coc.nvim, lsp bridge, kak-lsp, and other editor solution’s i’ve come across all opt to use sidecar processes that manage lsp. Perhaps Elisp isn’t the right tool for that backend processing.

This can be spun off into another thread. I haven't tried it yet but the feedback has been excellent.

https://reddit.com/r/emacs/comments/ymrkyn/async_nonblocking...

Oh what a great idea! I hope this can get mainlined someday(perhaps behind a config option) since Eglot should benefit from that approach as well!

This is a bit strange. I have Company setup to do the same thing and use it with Rust Analyzer and I have not experienced any stuttering at all!

I read down a bit and it seems like someone has mentioned building with "--with json", and this should be what makes the biggest difference here I think! The only thing I can think is that, maybe you didn't have libjansson installed while building Emacs, or it can't find it for some reason. It also needs to be available at runtime!

You can test to see if libjannson parsing is available by running '(json-available-p)' inside Emacs, in IELM for example.

Maybe some of this information will help!

Do you even get no stuttering with company-minimum-prefix-length set to 1 and company-idle-delay 0? I tried building --with-json, and `(json-available-p)` returns `t`, but it's still super stuttery.

I have the exact same settings on those specific variables. I do not experience any stuttering at all.

I am on a pretty powerful system though, I have a Ryzen 3900x and 32GB RAM which may be why I am not effected by this. I also have the garbage collection settings tweaked a bit. I am on version 29 for comparison.

In my experience it depends a bit on the LSP server itself (as well as it just being horribly slow in Emacs 27 and older). Omnisharp is for instance way slower than clangd and rust-analyzer. Also helps to make sure all the various mingw dependencies are there if you use Windows (json and native compile in particular). If you used LSP-mode it would be worth checking out if you can disable some of the information it renders to improve performance in general.

Other than that, Company can be a bit slow compared to Corfu, which is a bit more lightweight completion framework, built more around the emacs internals.

you can try https://github.com/manateelazycat/lsp-bridge

When I wrote that comment, in the depths of my soul, I knew someone would give a solution that needs me to invest more time in figuring out how to incorporate it into my oversized configuration.

But seriously, thank you, that is the performance I was looking for.

You can use Emacs for things other than programming :-)

Although I mostly use Emacs for my Python work, I still would use other IDEs for C++ work.

Emacs can and should be a good choice for programming though!

Emacs should be a good choice for everything, which is my point :-)

Just because you can't easily get it to be great at one thing (lsp) doesn't mean it needs to be abandoned for everything else.

LSP is so much better than alternatives to work with that I feel compelled to make it work and work well. Even for python, running pyright pays dividends for me. But luckily lsp-bridge looks promising so I don't feel like I need to jump ship for VS code quite yet.

To be frank, for Python I still use just elpy - it's good enough. The biggest headache I've had on Emacs with Python is dealing with virtualenvs.

If you are familiar with python I totally believe that. I find LSP to be the most useful in languages that I rarely use, of which Python is one. That way I can constantly, immediately and instantly see that I am doing it wrong.

Reply on news.ycombinator.com