Hacker News Reader

Comment by e3bc54b2 | Hacker News Reader

*eglot (short for Emacs polyGLOT)

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.

View on HN

> OTOH lsp-mode supports more than 1 active language server per buffer

for those editing html fes with css and javascript all in one file this is a showstopper

> OTOH lsp-mode supports more than 1 active language server per buffer

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.

I wish I knew more of the LSP surface area in order to know whether a "meta LSP" was feasible. IJ has something similar with "embedded languages" that it either ships knowing about, or a user can annotate an AST section with a comment (in the outer language's syntax) indicating the inner language; SQL language support in Java is the most recent example I can think of -- both of these situations allow inspection of the inner language:

    // 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 completing

It's a somewhat-supported thing; https://code.visualstudio.com/api/language-extensions/embedd... has some introduction to how it's often done.

My (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.

That was a super interesting link, thank you.

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

> egloty ... now comes with emacs so doesn't need any other packages (other than language servers themselves, of course).

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?

I understand where you are coming from, but in my case having anything be auto-installed is just a pain. My distro of choice is NixOS where installing stuff works fundamentally different from most other distros. When I tried it, lsp-mode just wasn't aware of it (not sure if it does now, but considering this space is vast, it is simply impossible to support every distro out there). Which means automated installation simply didn't work and I had to spend lot of time finding issues. For Emacs newbie it was a terrible pain.

Compared to that, I was done setting up Eglot + language server in 2 minutes flat, there was no config needed and it Just Worked!

On the other hand, "manually" installing LSP servers for me has consistently been running a single liner, with the huge benefit of being packaged in a predictable manner and updated alongside my system.

The idea of my lsp mode installing servers for me fills me with dread. I'm fine with, like, `brew install whatever-server` or `go get golang.org/x/tools/gopls` or whatever. But if lsp-mode's deal for installing a new language server happens not to work on my machine, I'm in for 45 minutes of elisp debugging to figure out what the hell is going wrong. Most languages we work in have more tooling than just a language server; we don't expect Emacs to install our debugger or code generator. It's weird that we expect it to install the lsp server.

It has language servers for lots of things. Things you may not even consider languages! HTML, CSS, JSON (and all its different usages and schemas), etc.

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.

> "non-free" (not GPLed)

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".

Permissive licenses are considered non-free by the FSF, or at least RMS.

He is very concerned about this, as you can see every time such a topic arises on the emacs-devel mailing-list.

No, they are not considered "non-free". Not even by RMS. Please provide evidence.

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.

lsp-mode also uses xref.

It has its own thingy, too, in lsp-ui, right?

Reply on news.ycombinator.com