Re: GUI and redisplay work (was: SVG widget in GNU Emacs)

[Alexandre Garreau]

Le mardi 26 octobre 2021, 14:32:15 CEST Stefan Monnier a écrit :
> > Ultimately I'd rather see effort go into getting pure gtk merged and
> 
> Yes, please.  This should be very high priority (sadly, this is way out
> of my area of expertise).
> 
> > the browser engine devs and use something like electron. I doubt the
> > emacs devs or maintainers would ever consent to running emacs on top
> > of chromium or webkit (although there's already the effort to have
> 
> I think fundamentally it would be great for Emacs to reuse some existing
> display engine rather than having to have our own.  But there are some
> important issues:
> 
> 1- We need to be able to open a 200MB log file with a snappy enough
>    performance to be usable (including with a bit of font-locking).
>    Most Web redisplay engines are not optimized for that case at all and
> many would tend to become completely unusable.  So if we want to use a
> web engine, we may still need some intermediate layer that feeds only
> part of the buffer to the underlying rendering engine.
> 
> 2- It needs to support all the features that we currently support.
>    Most engines provide *different* features from the ones we have,
>    rather than just strictly more.
> 
> 3- I plan for Emacs to still be around in 2050, but based on past
>    experience I suspect that all the current Web engines will
>    have been replaced before 2050.

All current Web engines derive from KHTML and Gecko, which are very old… 
wouldn’t the web engines in 2050 still derive from them, given their age?

On the other hand, TeX has now’ve been around for half a century, as long 
as emacs, and longer than the gnu (and nowadays main or even only 
seriously used) implementation of emacs, and it was several times (not 
only by me) drawn to attention as a layout engine whose structure/working 
might be interesting here (along with “bringing emacs on par with 
LibreOffice”, which also is an interesting comparison (LO still maintains 
its own display engine and doesn’t reuse gecko, servo, khtml, webkit, 
blink or anything like that right?)).

An important drawback is LibreOffice is imho slower than web browsers, and 
that TeX is atrociously slow compared to anything existing, due to the 
fact it was meant for one-time AOT compiling… and hence use *only* macros, 
and has no functions (by default, with its normal common evaluation) …
however ongoing current (I mean, since some years) attempt to improve 
TeX’s language/engine to make it faster but more importantly more 
readable, understandable (when you extend it a lot) and even more general, 
go into the direction of implementing real functions and complex and 
general datastructures on top of it (LaTeX3)… which seems to yet again 
lead a new language toward looking more like lisp… shouldn’t we take that 
as a hint or even encouragment?

We could also note that modern web engines have number of notorious 
drawbacks without attempts to be solved, such as typographical quality 
(TeX’s still leading, there), and performance (although they talk all the 
time about it, the very nature of the modern web (ephemeral pages and 
(proprietary) scripts rather than large files and long-lived (free) 
extensions) makes it mostly interpreted and way less efficient than a native 
gui such as gtk that emacs uses)…

And currently, am I wrong to suppose most emacs contributors are more 
familiar with TeX and GTK than the web, its engines and history?