Re: Elisp LSP Server

[Alexandre Garreau]

Le mercredi 3 novembre 2021, 04:18:07 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. ]]]
> 
>   > 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).
> 
> It sounds like this would turn Emacs into a sort of widget for use by
> websites.  That's not what we want Emacs to be.

Why so? is necessarily a widget a bad or diminutive thing? emacs is so 
important, that if emacs was a widget, then it’s not emacs that would be 
diminuished, but the notion of widget that would be enormously widened and 
improved.

All I say is I think emacs is often the best piece of software to look at 
source, and to edit anything textual in general.  Having emacs into a 
fully-functional graphical browser view is to me the easiest and most 
useful step before having a fully-functional graphical browser inside 
emacs.

Ofc emacs is deemed to dominate all userland anyway, once it’s mastered 
and sufficiently well integrated into workflow.  It’s the modern unix and 
userland implementation of what a LISP machine seemed to be, partially.

>   > 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).
> 
> How does a server know the names of files on your computer?

Here I was not talking about that: a such «src="file.c"» would mean the 
“file.c” file *relative to the url of the page* containing that.

But an url could as well point to a local file, I’m pretty sure that 1) 
it’s accessible with javascript via the html form element to select files, 
2) you can guess/reconstruct it according some previous value given by 
user, so you could have «src="file:///home/rms/Downloads/foo-repo/file.c”».

> Why does it want you to edit some specific file?

Possibly because you asked for it, because you were viewing source through 
a web browser, for instance because you didn’t cared to download the whole 
source tree locally.

>   > 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”
> 
> I can understand what it means to specify to go to a certain position
> in a file while visiting it in Emacs, but why would a web site
> do such a thing?

because currently github does it both in html pre (read-only), in html 
textarea (strictly less practical than emacs (except if you’re using w3m 
or some other browser that’s already launching emacs (actually $EDITOR) 
for editing any textarea)), or in VS Code (which is proprietary).

Actually, ideally I think viewing and editing of certain files in a web 
page should be agnostic of the application, so you could decide that html 
<video> should be viewed using vlc or mpv (preferably in-page, because 
it’s more ergonomical, it classify better your activities, and doesn’t 
break the flow with disruptives floating windows), or that file.c, or in 
general all textareas, should be viewed/edited using emacs.  It would be 
nice if, until emacs is a browser on par with firefox, firefox could trigger 
emacs (at least emacsclient) to edit stuff and view other such as source.

> The scenarios that I can envision are unethical ones, where your
> computing is done by a web site run by someone else, and thus not under
> your control. I can't think of an ethical scenario that would use this.
> 
> Can you describe one?

Source fragment samples on a personal blog, and the feature of allowing 
the user to benefit from personalized syntactic coloration, indentation, 
editing, and running what’s in the source snippet.

Many blogs do that nowadays, but all of them do that using proprietary 
javascript applications I think.  Or maybe some of them are free.  Given 
javascript “ecosystem” (I know you dislike this word and me too and I’m 
using it ironically) and culture, it would even be hard to know.  And even 
if it had a free-software license, I personally consider that javascript 
sent once-per-page-load is unarchived, unauditable, hence have many common 
issues with proprietary software.  I’d prefer if that was done with emacs 
and slime instead (and that’s already totally possible, what is lacking is 
an url convention to specify lines, <embed>-ing of arbitrary content 
(given the user has any software that can display/edit it), and 
mostimportantly and lacking and difficult: to display emacs inside a 
webppage).