[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Elisp LSP Server

From: Augusto Stoffel
Subject: Re: Elisp LSP Server
Date: Thu, 14 Oct 2021 15:34:38 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.60 (gnu/linux)

On Thu, 14 Oct 2021 at 07:00, Tim Cross <theophilusx@gmail.com> wrote:

> At any rate, I only entered this thread to address the misinformation
> about LSP being evil and encouraging the use of non-free software. LSP
> is simply a protocol - how it is implemented and how it is used is down
> to developers and users - arguing that providing an LSP server would
> encourage the use of non-free software is extremely unlikely. Elisp is
> of no interest to non-Emacs users and while it might seem that elisp is
> the greatest language ever to those who have drunk the Emacs kool-aid,
> to those outside Emacs, it is just some esoteric editor configuration
> language of little interest. 

I wouldn't paint LSP as being that neutral.  It is defined by Microsoft
and primarily with VSCode in mind.  Yes, they do take input from the
community and encourage other editors to support the protocol.  But
looking into the details, you notice that this aspect tends to be an

As a silly example, note that LSP defines methods such as "hover" and
"code lenses".  Whatever those VSCode features are, they could have used
a common name in the protocol.

As a more technical example, one can mention that the LSP completion
method doesn't return the bounds of the thing being completed (the
equivalent of START and END in `completion-at-point-functions').  There
have been several discussions on LSP's issue tracker about this problem,
cf. [1] and linked threads.  The conclusion, AFAICT, is that VSCode can
live with this limitation so the LSP protocol won't be fixed.

I think it's great to have an LSP client for Emacs, but it's important
to keep it as a simple translation layer between Emacs's editing
features and the current popular API for code analyzers (especially when
it's not a particularly well designed one).

[1]: https://github.com/microsoft/language-server-protocol/issues/648

reply via email to

[Prev in Thread] Current Thread [Next in Thread]