On Mon, Jul 25, 2022 at 5:08 PM Max Brieiev <
max.brieiev@gmail.com> wrote:
> Conceptually, Eglot matches a single major mode to a specific language server.
That is true.
> In some cases this is a limitation, because there are servers that are
> supposed to handle the project as a whole.
That is not the principal limitation, however. It could be in a
specific case but it's not a fundamental one. The limitation is rather
when multiple servers can operate on the same major mode of the same
project, offering different perspectives on your source code. Like one
language server dedicated to spelling, and the other to language things,
one dedicated to a specific linter, etc...
Often the language server itself aggregates these various perspectives
For example the clangd server offers optional support for the clang-tidy
linter, if it finds it.
But this is not always so and I think that some LSP clients do allow
multiple language servers to manage the same file. Eglot doesn't. It
requires significant (but not impossible) work on the base model. I'm
interested in hearing about a "killer use case" for this, i.e. in
hearing about a case where a user has been forced to choose just one of
twogreat language servers for a given major-mode.
On a tangent: the language server jungle is vast and growing every day.
The single greatest difficulty I have in understanding and addressing
bug reports to Eglot is reproducibility. It always starts with someone
working on language Foo using some special foo-mode.el and some special
foo-server with some special configuration and asking me to debug a
specific problem. Installing all these things (language toolchain,
foo-mode and foo-server) on my machine is very time-consuming, not to
mention debugging user's .emacs files. I just don't have the mental
bandwidth. It would be great if someone could work on some
"server-replayer" application that reads in Eglot event logs collected
from actual servers or synthesized event logs, so that these
installations aren't necessary. That would really speed up Eglot
development and bug-hunting.
> 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?
They surely could, but if there isn't some kind of consensus between the
major modes, it's not too difficult to extract a horizontal *minor* mode
that encompasses these differences. This is a common, effective Emacs
way of solving this problem. Then have the minor mode set
eglot-server-programs (or better yet, eglot-server-program) with the
correct invocation.
> Not sure whether Eglot supports this use case, but in the past I wasn't
> able to get it working.
It requires more coding, but it isn't extremely difficult. Have a look
at the SLY Common Lisp IDE and the sly-mode minor mode in particular.
It turns on in lisp-mode source files, and in special SLY buffers whose
major mode isn't lisp-mode and whose content isn't necessarily Common Lisp
source code. sly-mode sets and manages buffer-local variables that then
work for all intents are purposes as you describe.
The other difficulty you might face is that even doing the above with
Eglot today will probably result in multiple inferior server processes
being spawned (though now with the "correct" invocation). That may or
may not be a problem and depends on whether the LS has a distributed
architecture. If it doesn't, then Eglot also offers the TCP transport
model, where one single server is first started and then each inferior
process is actually a networking connection to that one process with a
single address space.
João