And major difference is eglot is slimmer compared to lsp-mode, integrates with and relies on built-ins more (xref etc) rather than inventing its own paradigm, is less cluttered by default and IME less buggier than lsp-mode cludge and now comes with emacs so doesn't need any other packages (other than language servers themselves, of course).
OTOH lsp-mode supports more than 1 active language server per buffer, generally support more features of the protocol than eglot and installs servers automatically (which may be a feature or bug depending on your system).
It comes down to utility and personal preference, but I've used lsp-mode before, found it quite buggy and cluttered, moved to eglot and have near zero LSP config now.
for those editing html fes with css and javascript all in one file this is a showstopper
If LSP survives, I'm certain solving this in the editor rather than the server this will come to be seen as an anti-pattern.
// IJ knows that "executeQuery" only accepts SQL string literals
// and the string is both highlighted and checked that "count" and "thing" are legal
statement.executeQuery("SELECT count(1) FROM thing");
// the following line designates the inner language
// language=SQL
String someSql = "WITH thing AS (SELECT whatever) SELECT * FROM thing";
With a language server, I'm guessing it would have to take the 2nd route, since I don't think language servers get into the business of knowing the semantics of the libraries against which they are completingMy (limited, from trying to hack a language server for a custom C preprocessor I have and reading a few others) experience is that language servers are not very good at true arbitrary composition but even the most monolithic ones are at least somewhat "wrappable". So a normal Java LSP wrapped in something that recognizes `executeQuery` and knows how to run additional checks on its string argument is possible. However, that thing running the additional checks on the string could not itself easily be an arbitrary SQL language server unless it was expressly designed for doing so.
The bigger issue is that you usually want some kind of semantic knowledge to cross the boundary! For example in HTML If I look for the definition of a string '#foo' in JS I want to jump to the element with ID foo; if I want to find uses of a .foo CSS selector I want to find the HTML documents with class="foo" and the JSX components with className="foo", etc. Isolating the servers misses most of the potential. You need a language-server-protocol-server protocol that can pass typed identifiers between each other; and now you've got not just programming problems but ontological problems which are the worst kind to have.
For the ontological problem, I presume you're referring to how there are so many differing ideas of how to represent ASTs (apologies for mixing languages, these URLs were just handy):
* https://lisperator.net/uglifyjs/ast#nodes
* https://github.com/estree/estree#the-estree-spec
* ... likely others
which makes it hard for ls1 to ask ls2 about "the for-of iteration variable Node" because ls2 could be using UglifyJS or ESTree or their own(!) AST nomenclature?
And all of this is made worse by (e.g.) Java1.3 versus Java19 because languages are rarely static
One of the things I love about lsp-mode is how it automatically installs any language server I need, when I need it.
I would rather install one package and be done, than use one built-in package, and have to manually hunt, download, and manually maintain language-servers for all the different languages I'm using in my programs, on all the machines I do programming on.
If eglot wants to become the defacto standard, it will need to solve this sooner rather than later.
But I suspect RMS will be opposed to having Emacs automatically download "non-free" (not GPLed) code?
Compared to that, I was done setting up Eglot + language server in 2 minutes flat, there was no config needed and it Just Worked!
What tooling would you install for that? What tooling does your system package-manager offer for that?
LSP-mode offering a “vertical” form of integration here (these major modes have been tested with these servers, and here’s how to install and invoke them) makes perfect sense to me as a user.
These two terms are not synonymous. Only proprietary software is "non-free". Software under free software licenses other than the GPL (whether copyleft or pushover/"permissive") is never considered "non-free".
He is very concerned about this, as you can see every time such a topic arises on the emacs-devel mailing-list.
Unsurprisingly RMS prefers GPL over pushover licenses, especially when it comes to Emacs and GCC, which he considers strategic tools in a fight against proprietary software. He has been opposed to depending on Clang when GCC is not suitable (again due to his fears that GCC would be used to build proprietary compilers), but this does not mean that he considers Clang to be non-free software.
It's odd, because vscode uses omnisharp over lsp and it is fast, powerful and reliable.