4 ms·

I’ve used lsp-mode for python, go, typescript, rust, and haskell. Had to do a little bit of fiddling with settings and trying different servers to get something

I’ve used lsp-mode for python, go, typescript, rust, and haskell. Had to do a little bit of fiddling with settings and trying different servers to get something performant for a very large python codebase, and I did some more fiddling to adjust some delays and whatnot to get everything feeling snappy with the way I edit text. I still find that it feels faster on Linux than on Mac, but I don’t use the latter much anymore anyway. My general impression of lsp-mode is that it’s great, once you get the settings the way you like them. Errors and warnings are nicely integrated into flycheck, and the lsp-ui package provides some niceties like automatically showing function signatures, showing error information inline with the code, and so on.

jonnycomputer 6y ago
It does actually sound like things have improved since when I started moving away from primary development in emacs circa 2016-17. It might be time to revisit my config file. I still end up coding in emacs a lot of the time.
- mplanchard 6y ago
  Emacs 27 helped a ton with language server performance, I believe because they reworked the JSON parser to be quite a lot faster. There’s also a “native-comp” feature that’s available experimentally in 28, which does native compilation of most of the .el files in emacs. I’ve played with it a bit and it does seem like a significant speed up across the board. Definitely a lot of exciting things happening!
  - TeMPOraL 6y ago
    Yup, Emacs switched to Jansson[0] for JSON parsing. Since LSP uses JSON a lot, this means big performance improvements there. Also seconding "native-comp" branch. It's technically experimental, but in practice it's pretty much stable. I've been running on it daily for the past 6+ months, with zero problems. The way it works is, it uses GCC (libgccjit) to compile Emacs Lisp down to native (vs. the EL bytecode Emacs normally uses) on the fly, and then replaces the byte-compiled function with its native-compiled version. It does it transparently, across all elisp code you use - built-in and thrid party alike. What you get is a huge performance boost, and occasional messages that something gets compiled, when you run some new elisp for the first time. -- [0] - https://digip.org/jansson/ https://digip.org/jansson/
neutronicus 6y ago
It doesn't really work for C++ Like it can, but not on our codebase

jonnycomputer 6y ago

It does actually sound like things have improved since when I started moving away from primary development in emacs circa 2016-17. It might be time to revisit my config file. I still end up coding in emacs a lot of the time.

mplanchard 6y ago
Emacs 27 helped a ton with language server performance, I believe because they reworked the JSON parser to be quite a lot faster. There’s also a “native-comp” feature that’s available experimentally in 28, which does native compilation of most of the .el files in emacs. I’ve played with it a bit and it does seem like a significant speed up across the board. Definitely a lot of exciting things happening!
- TeMPOraL 6y ago
  Yup, Emacs switched to Jansson[0] for JSON parsing. Since LSP uses JSON a lot, this means big performance improvements there. Also seconding "native-comp" branch. It's technically experimental, but in practice it's pretty much stable. I've been running on it daily for the past 6+ months, with zero problems. The way it works is, it uses GCC (libgccjit) to compile Emacs Lisp down to native (vs. the EL bytecode Emacs normally uses) on the fly, and then replaces the byte-compiled function with its native-compiled version. It does it transparently, across all elisp code you use - built-in and thrid party alike. What you get is a huge performance boost, and occasional messages that something gets compiled, when you run some new elisp for the first time. -- [0] - https://digip.org/jansson/ https://digip.org/jansson/

neutronicus 6y ago

It doesn't really work for C++ Like it can, but not on our codebase