Previous: Using Rassumfrassum, Up: Multi-server support [Contents][Index]
Using an LSP server multiplexer like rass relieves Eglot from
knowing about the specific characteristics of individual servers and the
complexity of managing multiple simultaneous server connections per
buffer. This helps preserve the essential features that distinguish
Eglot’s code base from other LSP offers for Emacs: simple, performant
and mindful of the core tenet of LSP, which is for a client to be
language-agnostic.
This approach has an additional benefit: because the multiplexer
mediates all communication between Eglot and the servers, it can take
advantage of different optimization opportunities. For instance, at the
system level it may be multi-threaded to process different JSONRPC
streams in with true parallelism, something which is currently
impossible to do in plain Elisp. At the LSP-level it can merge server
responses intelligently, truncate unnecessarily large objects, and cache
significant amounts of information in efficient ways. In many cases,
this can reduce the amount of JSONRPC traffic exchanged with Emacs to
levels well below what would occur if a client connected to multiple
servers separately. Some of these optimizations may apply even when a
program like rass is mediating communication to a single
server.
The multiplexer approach is not without drawbacks. Since LSP is a relatively large protocol with a decade of existence and many backward compatibility concerns, combining the responses of servers using completely different mechanisms of the protocol to respond to the same request sometimes leads to complexity in covering the corner cases. However, offloading this complexity to a completely separate layer has proven very effective in practice.