2 ms·
I've had a terrible experience with lsp-mode, gopls and Emacs 27. Minor issues like inconsistencies and CPU/RAM hogging that requires manual restarts, and the m
by imiric 5y ago
I've had a terrible experience with lsp-mode, gopls and Emacs 27. Minor issues like inconsistencies and CPU/RAM hogging that requires manual restarts, and the major one that made me stop using it is that Emacs would frequently crash when editing Go files.
I reported this to lsp-mode, but they kicked the can over to Emacs[1], which I never bothered reporting. The fact this is now a combination of tools with no clear reporting path when something goes wrong is awful UX.
Every few months I update the entire setup with hopes things improve, but eventually I always get the crashes. I would really like for this to work, as the DX when it does is great, but for me it's just not there yet.
[1]: https://github.com/emacs-lsp/lsp-mode/issues/3242 https://github.com/emacs-lsp/lsp-mode/issues/3242
- tsimionescu 5y agoI will just note that I have the opposite experience, as a daily user of go-lsp for about two years. It has been more reliable and much faster than the older Go modes I tried. It has also worked much better for me in Emacs than it does for colleagues using VSCode's integration with gopls. It's not without problems, occasionally taking quite a bit of processor power or needing the odd restart when it falls out of sync with a multi-module project, but it has never once crashed Emacs for me (using it on Ubuntu on WSL2, for what it's worth). I am not writing this to invalidate your experience. It's clear that something is rotten with the way the plugin uses emacs on your OS, and it's frustrating to not get help with that. I will note that their observation - that an Emacs crash is first and foremost is an Emacs problem, not a plugin problem - is fair though. But, I also would not want to go through a long series of communications between different projects, so I get your pain entirely.
- deleted 5y ago[deleted]