Re: Eglot to core [Was: rmsbolt.el [Was: Colorful line numbers]]

[Max Brieiev <max.brieiev@gmail.com>]

João Távora <joaotavora@gmail.com> writes:

> One of the points of bringing Eglot into core is that it can be used as
> a library by other major modes, who are free to build on top of Eglot's API.  Thus
> language server support becomes somewhat transparent (according to Stefan's
> recent definition): users don't need to know -- to some reasonable extent -- that Eglot
> as an LSP client is being used, just as they needn't know that tree-sitter is being
> used to provide, say, a better C++ mode.

Conceptually, Eglot matches a single major mode to a specific language server.

In some cases this is a limitation, because there are servers that are
supposed to handle the project as a whole.

This is especially the case in web development. The project may contain
various content types: javascript, stylesheets, html, xml, json,
typescript, syntax extensions like jsx, and so on.

This is where it is preferrable to have a single server instance per a
number of major modes. The server may read project configuration file
from the project's root directory, or be passed appropriate
initialization options during server startup.

If major modes were to use Eglot's API in their own ways, wouldn't they
step on each other toes - e.g. each one passing conflicting
initialization options to the server?

Not sure whether Eglot supports this use case, but in the past I wasn't
able to get it working.