emacs-devel
[Top][All Lists]
Advanced

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

Re: Elisp LSP Server


From: Tim Cross
Subject: Re: Elisp LSP Server
Date: Wed, 13 Oct 2021 11:31:59 +1100
User-agent: mu4e 1.7.0; emacs 28.0.60

Richard Stallman <rms@gnu.org> writes:

> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
>   > Aside from what Stefan mentioned, lsp-mode has another problem: it
>   > encourages users to, and even automatically downloads proprietary
>   > software from the internet.
>
> This suggests that lsp-mode is poison.  Recommending it in Emacs might
> put us in a morally contradictory position.
>
> Would you please explain more about this?  Perhaps give some names to
> the programs in the scenario, and say how they relate to each other?

I think the LSP situation has been both misrepresented and
misunderstood.

There is nothing inherently evil about LSP. It is just a protocol. There
is nothing in LSP which requires proprietary software or use of non-free
services. There can be instances of LSP implementations which might do
this, but that is about the implementation and not about support of the
protocol. Ironically, the first place I ever heard about/discussed a LSP
like solution was on this list many years ago during discussions about
how to provide better and more consistent support for things like
completion, syntax highlighting, linting etc. At that time, it was
acknowledged that one reason many editors built for a specific language
were able to provide more superior support in these areas was because they
had a built-in parser for the language being used and that for Emacs to
provide something similar would require it had the ability to parse each
language being supported. This triggered efforts like the one to allow
Emacs to leverage of Eclipse to provide enhanced language support for
Java and to some extents, efforts like CEDET and Semantic.

The basic idea behind LSP is an extension of this idea. In an ideal
world, every programming language would also include an LSP language
server. It would be maintained in parallel with the development of the
language. Any editor which wanted to support that language would
implement the client side of the LSP protocol and install the language
provided LSP language server, avoiding the need for each editor to
implement it's own version of a language parser in order to provide more
'intelligent' support for things like completion, API documentation,
linting, etc.  

The fact MS has used LSP to provide enhanced features on github has
nothing to do with LSP directly - Github integration is not a required
part of the protocol and is not mentioned in the LSP sepcs. You are not
required to use github because you use LSP. Likewise, your not required
to use VSCode extensions, although some languages might distribute their
LSP language server components via that service. Likewise, language
servers for LSP may or may not be free and may or may not encourage use
of non-free software - it needs to be evaluated based on each LSP
language server.

Even if a language server is distributed via github and to use it you
have to download the server from github, this is not sufficient justification
not to support LSP. We already have a number of packages in ELPA and
nongnu ELPA where the main repository is on github. 

I am ambivalent about an LSP language server for ELISP. This is mainly
because all the bits an LSP language server provides are already part of
Emacs and partly because I don't see any real benefit or use case for
ELISP outside of Emacs (I know there are some out there who would like
to use Elisp for everything, but I feel that is an example of a 'hammer
looking for a nail' type syndrome - just because Elisp can be used as a
general purpose programming language doesn't mean it should be).

I suspect that if you configured Emacs to use the same key bindings for
Elisp support features, so that when developing Elisp code it 'felt' the
same as when developing code for an LSP supported language, you would
satisfy much of the requirements raised by the OP.

Having said that, if someone wants to have a go at developing an LSP
language server for Elisp, I would encourage them to do so. While I
suspect they will soon find the amount of work required and the benefits
it provides difficult to justify/maintain, it does no harm and it may
result in other benefits and is a project which would likely provide a
good platform for expanding/enhancing an individual's elisp knowledge at
a deeper level.

In summary, for the OP,
- No, I don't think anyone has tried developing an LSP server for Elisp
- Sure, if you want to do it, go for it
- No idea what language to use or how to implement the server. It has
been suggested elisp would be the obvious choice, but I don't see how
you can implement elisp outside Emacs without pretty much implementing
most of emacs. Other language servers have used Rust or Go to implement
the language parser. I guess it will be whatever language you feel is
best to implement an elisp parser outside of elisp. 



reply via email to

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