On Mon, Jul 25, 2022 at 5:08 PM Max Brieiev 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