Re: GUI and redisplay work

[Alexandre Garreau]

Le vendredi 29 octobre 2021, 21:29:43 CEST Alexandre Garreau a écrit :
> Le vendredi 29 octobre 2021, 19:34:14 CEST Arthur Miller a écrit :
> > Have you checked out Nyxt browser?
> > 
> > https://nyxt.atlas.engineer/
> > 
> > CL + another widget derived from khtml ...
> > 
>> […]
> 
> […]
>
> The final problem

[hit ctrl by accident, sorry)

The final problem, common with that extension/non-emacsness as well, and 
present as well in TeXmacs, is that you can’t use that software (yet, as 
you said) to edit itself, which greatly diminuish the benefits of self-
extension and dynamism, because you loose a part of the benefit of self-
documentation combined with the integratedness of the development 
environment… to allow that among various programs, as it is already 
natural among various emacs’ extensions (which often provides a whole app, 
actually, as it would modernly be called), would require a whole inter-
program system of hyperlinking, along with sharing of many informations 
about the running program (which within emacs, or, what it comes from, a 
lisp machine, isn’t needed since all data is shared, you don’t even have 
to duplicate it)…

> > I am quite sure someone could develop a text editor based on "web
> > technologies" or just in pure CL that works in Nyxt.

…furthermore, a final manifestation of that is precisely that it would be 
very handy to have an editor inside a such program, however one bad and 
one great thing:

The bad one is that if what the vision of emacs provokes is the 
proliferation of editors, it becomes increasingly unpractical, as with 
each editor you would loose the benefit of the other ones: it would be hard 
to synchronise useful extensions and configurations among many editors, and 
a consequent work to normalize a common interface to make those compatible 
among them… Moreover, emacs is already in the picture since almost half a 
century, and many many many very useful extensions have been developed for 
it, even some you won’t find on any repository, on some old ftp server, 
that exists since longer than I’m born, even some you actually won’t find 
on the internet, but some people would happily share as soon as they’d 
become useful to you (such as specific to some projects), and that would be 
a great loss to abandon that, by switching to something incompatible.

Also something imho of first importance: anything can be an editor.  The 
very concept of editing is very broad, and is appliable to almost anything 
that’s not used passively for viewing.  Emacs is, outside of file editing, 
mainly used for irc and mails: anything involving text-editing can benefit 
from it (and that’s most of the usage of a computer nowadays, that’s why 
we can spend so much time inside emacs).  So I think ideally every 
software should be considered as an editor and share a part of 
customization/functionality with each other (even if only for text 
editing… but there’s also interactive macro registration, keyboard 
association and triggering, among other abstract things that would be 
useful everywhere).

And that would be mostly useful for the web, which became symmetric for 
most people only thanks to “social medias” that take control on their 
data.  But the first web browser was not a viewer, but a viewer/editor, and 
was hence de facto totally symetric in functionality, even from remote 
(thanks to HTTP PUT command, taken from ftp, which also is pretty symetric 
in usage), and didn’t need “web 2.0” for that.  “Web 2.0”, which, 
basically, means using software server-side to store and dispatch user’s 
data, which necessarily involve diverse, non-standard and likely 
incompatible software that could easily grow into SaaSS, or silo whose 
it’s not possible to automatically retrieve personal information…

That’s because most of web browser quickly stopped supporting editing to 
become passive tools of information (from editors to users), where you 
need more skills to express yourself than to read others.  Most of people 
can’t write html (or understand the concept of markup, hence more 
generally computer language), don’t know how it works, and if only 
Firefox’s inspector wouldn’t be so complicated and debugging-oriented it 
could make it way more intuitive to gradually discover (just like many 
users gradually discover programming with emacs).

If only a such browser existed it would be easy to make the web better 
understood, hence the javascript trap, and proprietary software along with 
SaaSS, and how they can be avoided.