Re: Elisp LSP Server

[Tim Cross]

Alexandre Garreau <galex-713@galex-713.eu> writes:

> Le samedi 30 octobre 2021, 08:51:37 CET Richard Stallman a écrit :
>> [[[ 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. ]]]
>> 
>>   > > You can already start Emacs locally.  What's the actual point or
>>   > > goal
>>   > > here?
>>   > 
>>   > you cannot from webpages,
>> 
>> I can't imagine what it would mean to "start Emacs from a web page".
>> Can you please explain concretely?  Please keep in mind that some of
>> us have never seen it.
>
> To me it would mean to have something written in the page’s source that 
> would trigger emacs to be launched, and possibly its window to be 
> displayed as part of the page (that is: without decoration or ability to 
> be moved, and it would scroll with the page’s content and wouldn’t be 
> displayed if the browser’s window’s not).
>
> What I would imagine would be for instance <embed src="file.c" /> or 
> possibly with attributes specifying that we want to open it with emacs or 
> at line n (I’m sure standards exist for those, there is certainly some 
> anchor syntax for within github to point at a line, something like 
> file.c#l123).
>
>> With a concrete picture of the practice in question, we could start to
>> think about the practical and _moral_ implications of supporting that
>> in Emacs.  How would it affect the development and use of the GNU
>> system? How would it affect our fight against unjust computing?
>> 
>> We could also think about how we would want to implement it, if we
>> decide to try.
>> 
>> The more closely and seamlessly Emacs becomes integrated with some
>> other program's user interface, the more it undermines our goal of
>> making users aware of GNU Emacs, and of the ethical goals that we
>> develop GNU Emacs (and GNU as a whole) to promote.
>
> Oh that’s a valid concern I didn’t thought about…
>
>> That suggests that perhaps the best way to do this job is via
>> emacsclient.
>
> Indeed.
>
>>   >   The issue is you can follow an hyperlink from emacs (or any
>>   > 
>>   > software, for the matter) to the webbrowser, but more hardly from
>>   > the
>>   > webbrowser to some specific function of emacs
>> 
>> I'm not sure how to understand the idea of invoking a "specific
>> function of Emacs" from a browser.  Would you please give a couple of
>> concrete examples?  Which functions of Emacs would you suggest we
>> support imvoking in this way, and how would they be used in the
>> scenario?
>
> open at line, open with a certain mode enabled, open several files at once, 
> open an svg file either as an image or as source, etc.
>
> the main one being “open at line”
>
>>   >  yet these represent most of the usage of their
>>   > 
>>   > computer from modern users.
>> 
>> That is not necessarily a recommendation of it.  Quite the contrary:
>> there are a lot of bad developments in modern computing.
>> Most of the computing people do nowadays is for suckers.
>> Surveillance companies have a lot of influence over what people
>> do on the internet, and how they do it.
>
> Yes of course.
>
>> The question of when to go along, and how far, is sometimes
>> obvious, and sometimes subtle.
>
> As I said: I think the way I propose would be strictly in benefit of emacs 
> (it would drag people from the browser to emacs, which is going to be more 
> full-featured and faster anyway). It would also for users because it would 
> remove the need for javascript in certain cases that are going to 
> proliferate (people programming inside their browser), so they could avoid 
> it.

I'm sorry, but this argument makes no sense to me.

This whole argument assumes the user has emacs installed. If they don't
use emacs, it is unlikely they have it installed and if they do use it,
then it isn't going to attract any new users.

I also don't understand the argument of avoiding javascript - the only
way to interact with an API or a LSP server or emacsclient from within a
web page is via some form of script execution and the only scripting
language universally supported inside a browser is javascript (possible
exception is with a browser extensions, but that would need a browser
specific extensions for each browser type).

I also don't see how this relates at all to an elisp language LSP
server. So far in this thread, the only person who seems to have come up
with a valid justification for an LSP server is Eli, with his suggestion
that an elisp LSP server running in a separate Emacs instance could
provide an efficient mechanism for offloading processing to a separate
process, thereby improving emacs performance (a poor mans
multi-tasking if you like).

If you had access to an elisp LSP server from within a web browser, that
would still require lots of javascript to handle the embedded 'window' -
having an elisp LSP server is not going to suddenly enable Emacs to
embed an Emacs frame/window inside a web page. The best you could do is
use the elisp LSP server for parsing, adding face properties, completion
etc. You would still need javascript to manage the display and
navigation within the embedded 'window'. .

Note also that there already exists a browser extension (chrome and
firefox, though I don't know about the firefox extension post the
firefox API changes a few years ago), which allows you to use Emacs to
edit any editable field in a web page. The 'with-editor' extension adds
an 'emacs' button to editable fields in a web page - clicking on that
pulls up a new emacs frame (via emacsclient) which allows you to use
Emacs to edit the data. Once you close the frame, the data is updated in
the browser page field.

I disagree with RMS and others fears regarding the implications of an
elisp LSP server. I feel this is 'tilting at windmills'. Emacs and elisp
are great technologies, but they are of little to no interest to
non-emacs users. Just because it would be technically possible to call
an elisp LSP server from a non-free program does not mean that provision
of such an LSP server would result in either Emacs/elisp being used by
non-free software or in some way encouraging free software users to use
non-free software. The real benefit of elisp is in the whole environment
that Emacs provides. The limited functionality provided via the LSP
protocol cannot reproduce that environment and at best, would only
provide access to functionality which is already available via other LSP
servers which are likely to be more familiar to non-Emacs users than
elisp.

... and of course, all of this is primarily vapourware based on a
fleeting thought with no real substance. I would encourage anyone who
feels it is worth fleshing out further to do so and the rest of us wait
until something of substance exists before debating pros and cons. For
all we know, implementation of an elisp LSP server may result in other
benefits not yet thought of which could be extremely valuable to the
Emacs community. We should encourage such developments rather than
discourage them based on vague and unsubstantiated fears.