Getting LSP integrated pervasively in Emacs in a way that it reliably just works and performs well out of the box
I don’t get how this should work, when setting up LSP servers is now the issue. If you want to use rust-analyser, you have to download rust-nightly. If you want to use a Java LSP server, you have to do class-path magic. If you want to use a Python LSP server, you’ll have to let pip download every single python library again to get the right versions. If you want to compile a Haskell LSP server, you’ll need to buy some more RAM.
But if this would be solved, and all I have to do is run “sudo package-manager install java-lsp-server”, then it would be a considerable advancement. The best one can do, as I understand is planned for 28.1, is to get Eglot into a working and stable state, so that it’s ready for when the server implementations have matured.
Having a wizard showing up in new Emacs installations might be a great low-hanging fruit way of making Emacs more accessible.
I have discussed this on the mailing list, but haven’t ever had the time to implement this myself (yet). What Emacs needs is a wizard language, that can be used to teach Emacs itself, but also any package (just like ert is used for tests). Most proposals haven’t been too pretty though.
Take a look at the screenshots of these Neovim GUIs:
I don’t see any notable difference, tbh. What I would get is better integration into window managers (opening downloaded files in existing emacs sessions), but I have never understood what neovim actually achieves by splitting UI and backend. Sure, it’s a good design decision in principle, but considering the complexity of Emacs display engine, I’m not sure if it is worth it.
It is very easy to either freeze Emacs or cause it to run very slowly. Multiple times a day I have to hit C-g incessantly to bring it back from being frozen. When that fails, I am sometimes able to get it back with pkill -SIGUSR2 Emacs. At least once per week I have to pkill -9 Emacs because it turned completely unresponsive.
I used to have these problems, but in my experience this comes from fighting Emacs instead of cooperating with it. Using unnecessary packages, weird themes and wanting popups everywhere will simply slow stuff down. The main parallelism in Emacs is done by starting external processes, since Emacs is more of a Unix shell than Lisp machine.
It would be great to have more and more of these influencing and being incorporated to the Emacs Lisp standard library and made to be very performant.
Please not, dash and s are quite annoying and don’t always lend themselves to idiomatic Elisp (I understand they are influenced by Clojure, which has a difference heritage). seq.el and map.el are nice, but since they are based on generic functions, they are often slower.
It would be great to move to a forge style of contribution.
As long as it doesn’t require new accounts, and everybody is free to participate in the conversations, ok, but I’ve only seen this implemented by source-hut, and none of the GitHub clones that have spoiled so many people.
Strongly agree with this. It’s extremely good as a “visual shell” / UI framework. It’s not usually a good UX when you try to implement too much of your world in Elisp with dozens of packages, spinners, networking, etc. You end up in C-g hell as the author describes. Over 15 years of usage I’ve actually evolved away from the “rewrite everything in Elisp” view and towards “drive scripts from Elisp and slurp results into a buffer for processing”
Please not, dash and s … don’t always lend themselves to idiomatic Elisp
Also agree. Writing idiomatic Elisp using the built in APIs isn’t that hard, but it’s more “old skool” and can be imperative/verbose, so I guess some people don’t like it
On the other hand I think it’s kind of dumb to have to import a “cool” string library to install a library that does something I actually want.
Elisp isn’t Clojure and I’m glad for that. I think a lot of the complaints are that it isn’t Clojure/CL/etc, but its not supposed to be. It’s basically a 70s era MacLisp clone.
In general I think two (no three) things:
People can write whatever they want to write, it’s free software, their itch etc
I wish a lot of the people trying to make Emacs “better” (by their definition) but who are also possibly adding complexity to the code base, changing variables and APIs and default settings etc would just chill and learn more about what it is they’re trying to change before concluding “this needs feature X, let’s hack it in and now everyone has to live with it”
I know #2 is something of a straw man and not 100% fair but Emacs is where I live all day every day and somebody else’s “cool new feature” is my “unnecessary risk and complexity” (and possibly lost hours troubleshooting)
Take a look at the screenshots of these Neovim GUIs:
I don’t see any notable difference, tbh. What I would get is better integration into window managers (opening downloaded files in existing emacs sessions), but I have never understood what neovim actually achieves by splitting UI and backend. Sure, it’s a good design decision in principle, but considering the complexity of Emacs display engine, I’m not sure if it is worth it.
The exactly same thing has been said for vim, yet neovim managed to pull if off. Just for the sake of it being a great design decision, it would be worth implementing it. The case in points are so many different forks of emacs, trying to make it run on different platforms (emacs-mac, xemacs, …).
I don’t get how this should work, when setting up LSP servers is now the issue. If you want to use rust-analyser, you have to download rust-nightly.
This imo is exactly the problem which should be solved by editor’s extension. In VS Code, the user just installs the rust-analyzer extension and the binary is downloaded automatically. IIRC, coc-nvim provides a similar experience.
It is important that LSP support in an editor allows for each language to have a dedicated, easy discoverable plugin which deals with dirty integration bits.
I’ve had pretty hit-or-miss luck with things actually working in VS Code when you do that. Just yesterday I tried using it for C# for the first time, responded “yes” to the prompt when it asked if I wanted to install the recommended C# extensions, and now I have some kind of dependency hell around .NET version mismatches (“Error: The reference assemblies for .NETFramework,Version=v4.7.1 were not found.”). Some of the language extensions install without problems, but I’ve come not to expect it.
That’s basically the same problem as with rustup, that I have to install software from external sources, instead of having it all done by my (system’s) package manager.
You can consider using Nix to declaratively create project development environments that includes build tools like LSP servers, which is exactly what I do in my open source Haskell project (run nix-shell --run "code ." and things “just work”, be it on Linux, macOS or WSL).
I used to have these problems, but in my experience this comes from fighting Emacs instead of cooperating with it. Using unnecessary packages, weird themes and wanting popups everywhere will simply slow stuff down.
I don’t think it’s productive to put blame for these problems on the user. Extensibility is the main selling point of Emacs for many, people use it because they want those features. Of course it’s always possible to shot oneself in the foot. But if some of the problems are solvable on the level of platform, they should be solved there. When I pick a theme I want to pick it for its look and not think if it will slow down my editor. If an extension delays startup, becomes unresponsive or slows down every key stroke I want to be told by Emacs about what’s to blame but I also want it to be hard to achieve.
It shouldn’t be as easy to bring the editor to a crawl. The user doesn’t have to be an expert or to use vanilla Emacs for it to be fast. The machine I’m typing this on has 8 cores, I don’t see why crazy computations to paint parentheses in rainbow colours should slow down my typing or scrolling. I think support for asynchronous execution is one of the main reasons why Neovim succeeded.
Extensibility is the main selling point of Emacs for many, people use it because they want those features.
What features? My comments are more related to UI stuff like pop-ups or constant redrawing effects – in other words non-functional aspects. They can be nice and fun, but since most of the time they are hacks, it’s nor surprising that they aren’t efficient.
If an extension delays startup, becomes unresponsive or slows down every key stroke I want to be told by Emacs about what’s to blame but I also want it to be hard to achieve.
The problem here is that there is no such thing as an extension. There is no means to distinguish between the core and (so-called) extension, because they are equal.
It shouldn’t be as easy to bring the editor to a crawl.
As an editor, yes, but again Emacs is a fully programmable environment. Evaluate
(defalias 'eval #'identity)
and slowly everything will start to break. Emacs’ power necessarily includes the ability to break stuff. The barrier can be lowered, but adding more (finite) computing power doesn’t solve the “issue”.
But if this would be solved, and all I have to do is run “sudo package-manager install java-lsp-server”, then it would be a considerable advancement.
I’ve only tried clangd, which I was able to just grab via my distro’s package manager and it just worked (other than that every few hours clangd gets OOM killed…)
I don’t get how this should work, when setting up LSP servers is now the issue. If you want to use rust-analyser, you have to download rust-nightly. If you want to use a Java LSP server, you have to do class-path magic. If you want to use a Python LSP server, you’ll have to let pip download every single python library again to get the right versions. If you want to compile a Haskell LSP server, you’ll need to buy some more RAM.
But if this would be solved, and all I have to do is run “sudo package-manager install java-lsp-server”, then it would be a considerable advancement. The best one can do, as I understand is planned for 28.1, is to get Eglot into a working and stable state, so that it’s ready for when the server implementations have matured.
I have discussed this on the mailing list, but haven’t ever had the time to implement this myself (yet). What Emacs needs is a wizard language, that can be used to teach Emacs itself, but also any package (just like ert is used for tests). Most proposals haven’t been too pretty though.
I don’t see any notable difference, tbh. What I would get is better integration into window managers (opening downloaded files in existing emacs sessions), but I have never understood what neovim actually achieves by splitting UI and backend. Sure, it’s a good design decision in principle, but considering the complexity of Emacs display engine, I’m not sure if it is worth it.
I used to have these problems, but in my experience this comes from fighting Emacs instead of cooperating with it. Using unnecessary packages, weird themes and wanting popups everywhere will simply slow stuff down. The main parallelism in Emacs is done by starting external processes, since Emacs is more of a Unix shell than Lisp machine.
Please not, dash and s are quite annoying and don’t always lend themselves to idiomatic Elisp (I understand they are influenced by Clojure, which has a difference heritage). seq.el and map.el are nice, but since they are based on generic functions, they are often slower.
As long as it doesn’t require new accounts, and everybody is free to participate in the conversations, ok, but I’ve only seen this implemented by source-hut, and none of the GitHub clones that have spoiled so many people.
Strongly agree with this. It’s extremely good as a “visual shell” / UI framework. It’s not usually a good UX when you try to implement too much of your world in Elisp with dozens of packages, spinners, networking, etc. You end up in C-g hell as the author describes. Over 15 years of usage I’ve actually evolved away from the “rewrite everything in Elisp” view and towards “drive scripts from Elisp and slurp results into a buffer for processing”
Also agree. Writing idiomatic Elisp using the built in APIs isn’t that hard, but it’s more “old skool” and can be imperative/verbose, so I guess some people don’t like it
On the other hand I think it’s kind of dumb to have to import a “cool” string library to install a library that does something I actually want.
Elisp isn’t Clojure and I’m glad for that. I think a lot of the complaints are that it isn’t Clojure/CL/etc, but its not supposed to be. It’s basically a 70s era MacLisp clone.
In general I think two (no three) things:
The exactly same thing has been said for vim, yet neovim managed to pull if off. Just for the sake of it being a great design decision, it would be worth implementing it. The case in points are so many different forks of emacs, trying to make it run on different platforms (emacs-mac, xemacs, …).
This imo is exactly the problem which should be solved by editor’s extension. In VS Code, the user just installs the rust-analyzer extension and the binary is downloaded automatically. IIRC, coc-nvim provides a similar experience.
It is important that LSP support in an editor allows for each language to have a dedicated, easy discoverable plugin which deals with dirty integration bits.
I’ve had pretty hit-or-miss luck with things actually working in VS Code when you do that. Just yesterday I tried using it for C# for the first time, responded “yes” to the prompt when it asked if I wanted to install the recommended C# extensions, and now I have some kind of dependency hell around .NET version mismatches (“Error: The reference assemblies for .NETFramework,Version=v4.7.1 were not found.”). Some of the language extensions install without problems, but I’ve come not to expect it.
haskell language server provides precompiled binaries that transparently download for vsode, and lsp-mode is working on reusing this ability.
You can also install prebuild binaries via ghcup
That’s basically the same problem as with rustup, that I have to install software from external sources, instead of having it all done by my (system’s) package manager.
You can consider using Nix to declaratively create project development environments that includes build tools like LSP servers, which is exactly what I do in my open source Haskell project (run
nix-shell --run "code ."and things “just work”, be it on Linux, macOS or WSL).I don’t think it’s productive to put blame for these problems on the user. Extensibility is the main selling point of Emacs for many, people use it because they want those features. Of course it’s always possible to shot oneself in the foot. But if some of the problems are solvable on the level of platform, they should be solved there. When I pick a theme I want to pick it for its look and not think if it will slow down my editor. If an extension delays startup, becomes unresponsive or slows down every key stroke I want to be told by Emacs about what’s to blame but I also want it to be hard to achieve.
It shouldn’t be as easy to bring the editor to a crawl. The user doesn’t have to be an expert or to use vanilla Emacs for it to be fast. The machine I’m typing this on has 8 cores, I don’t see why crazy computations to paint parentheses in rainbow colours should slow down my typing or scrolling. I think support for asynchronous execution is one of the main reasons why Neovim succeeded.
Hard agree.
What features? My comments are more related to UI stuff like pop-ups or constant redrawing effects – in other words non-functional aspects. They can be nice and fun, but since most of the time they are hacks, it’s nor surprising that they aren’t efficient.
The problem here is that there is no such thing as an extension. There is no means to distinguish between the core and (so-called) extension, because they are equal.
As an editor, yes, but again Emacs is a fully programmable environment. Evaluate
and slowly everything will start to break. Emacs’ power necessarily includes the ability to break stuff. The barrier can be lowered, but adding more (finite) computing power doesn’t solve the “issue”.
rust-analyzer provides pre-built binaries
I’ve only tried clangd, which I was able to just grab via my distro’s package manager and it just worked (other than that every few hours clangd gets OOM killed…)
Oh ho, actually it will be
M-x inferior-neuralink.I’ll see myself out. :)