Re: Elisp LSP Server

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Cc: luangruo@yahoo.com, agzam.ibragimov@gmail.com, philipk@posteo.net,
>       psainty@orcon.net.nz, emacs-devel@gnu.org,
>       joaotavora@gmail.com, mardani29@yahoo.es
> Date: Thu, 14 Oct 2021 18:26:01 -0400
> 
> The proposal at issue -- unless I have misunderstood -- is to develop
> a server interface for Emacs specifically to make those analysis
> results available to other editors (which may mean, principally
> VScode).

That interface will be first and foremost useful for Emacs, because
that's the main/only editor people use to edit Emacs Lisp programs.
It's true that other editors will be able to use that, but the chances
of someone using VSCode to edit Emacs Lisp are slim at best.

> If I understood right, this can't be of any benefit to editing with
> Emacs.  Because all the analysis results we can produce will be
> available anyway for editing in Emacs.

This assumption/conclusion misses an important point, see below.

> Would it be possible to make Emacs launch a child Emacs and use it as
> a language server to get the results of these analyses?  I suppose so.
> Just as it is possible to launch Emacs inside M-x term and edit in
> that child Emacs.
> 
> Is there is any practical advantage to starting a child Emacs to do
> this analysis in?  I don't see it.  Why not do it in the initial Emacs
> process?

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.  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).