Re: Elisp LSP Server

[Philip Kaludercic]

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. ]]]
>
>   > > I think it is dangerous for Emacs to "integrate" with such proprietary
>   > > software.  It would make people gravitate towards that software.
>
> Po Lu is right.
>
>   > That yes, but that is an inherent problem of LSP (e.g. see how VSCode
>   > can automatically download and run a propitiatory LSP server like
>   > Pylance), and not the "." command itself.
>
> Can you please explain the problem that you're talking about?  If it
> is true that LSP inherently tends to use nonfree LSP servers, then
> using LSP is inherently a problem, and maybe we should not include
> that feature in Emacs at all.

I don't think that this is currently the case, most LSP servers I know
of are free software.

The difference between Emacs (at least Eglot) and other LSP
implementations, is that the latter can download servers automatically.
This is done without regard to the license, as projects like VSCode are
not focused on software freedom. The intent is to take care of setting
up a server without the user having to care, but the effect is that
actual programs, possibly propitiatory, are being downloaded and run on
the host system.

> Or can we fix that problem?  Maybe loading nonfree servers is not
> totally inherent -- maybe we can arrange to avoid it.

Of course. Currently the problem doesn't exist to begin with, since LSP
servers have to be installed manually for Emacs.  If LSP clients for
Emacs were to automatically configure a server, then I do think that the
licensing should be seriously taken into consideration. 

>   > I think a better solution to Ag's problem is to make editing online
>   > repositories easier, without to manually clone a directory every time.
>
> Would you spell out in more detail what you're thinking of?  Perhaps this
> would be a solution, but what is the solution, and what is the problem?

The problem is when you are browsing the online interface of a source
code repository, you might decide to want to make a change. This
introduces friction in the user's workflow, because you have to find a
directory, the repository has to be cloned into said directory, opened
in Emacs and then you can start working.

GitHub has introduced a feature where a in-browser Editor (derived from
VSCode as far as I see) can be invoked by literally at the press of a
button. Everything has been initialized, and you can make your changes
in a matter of seconds.

Replicating this for Emacs seems hard to do, but it is probably the
wrong approach. My guess would be that most people wouldn't want Emacs
in a browser. A solution could be to provide a script or command that
automatically clones a repository to a temporary directory and opens
Emacs (possibly by making use of emacsclient). The tricky part would be
to integrate this into a web browser, but my guess would be that this
could be done by use of a browser extension. This would recognize the
website, extract the git repository and start the script.

Haven't tried any of this, it is just brainstorming.

-- 
        Philip Kaludercic