Re: Elisp LSP Server

[Tim Cross]

Eli Zaretskii <eliz@gnu.org> writes:

> Doing that in the same process will make Emacs slower, because Emacs
> is fundamentally single-threaded.  On modern systems that routinely
> have 8 or 16 execution units, off-loading some of the processing to
> asynchronous code that exploits additional execution units is a
> significant advantage, and allows us to be much more scalable.  If
> Emacs had true concurrency, we could do that in the same process by
> arranging for additional threads.  But since that is not available,
> running a language processor in a separate process is the next best.
> And since a protocol for that already exists, reusing the protocol in
> this case sounds like an idea worth exploring.

That is an aspect I hadn't considered. Given the number of desktop
systems sitting there with most cores doing nothing, this could be a
useful addition indeed. 

> Of course, if it turns
> out the LSP protocol doesn't help much, we could always implement our
> own protocol (which would then solve the fear of VSCode using that,
> although I think that's us being haunted by the shadow of a dwarf).

I love that expression - it succinctly sums up my feelings concerning
the fears raised in this thread.