Re: Emacs design and architecture

[Dmitry Gutov <dmitry@gutov.dev>]

On 15/09/2023 12:32, Gerd Möllmann wrote:
> I think it would maybe be good to think about the following:
> 
> Random thoughts about a parallel redisplay, from a height of 10 km.
> 
> What currently happens to bring changes to the screen is that redisplay
> is called quite frequently in the course of processing input for
> example.  Redisplay determines what part of the a "model" (buffer) has
> changed, if any.  It makes sure that all info it needs to proceed is
> available; think jit-lock, i.e. it calls Lisp. Because redisplay is
> called frequently, it must minimize what it does, which is the reason
> for the complicated optimizations there.
> 
> Whatever is done in the end, I think it would first be necessary to
> change this general principle, so that layout/drawing whatever can
> happen in parallel.  Without that, I suspect redisplay would get too
> slow, or would finally collapse to a black hole by its complexity.

I think it'd be an interesting project to study how an existing Emacs 
could output into a web page. Or a web driver, etc. How a "toolkit port" 
into HTML/JS could work.

That system is historically more complex than what you described, 
including lots of callbacks, e.g. it might be possible to implement 
jit-lock using the 'DOMContentLoaded' and 'scroll' events.

Consequently, though, parallel layout has been historically a hard 
problem for web browsers, but the current engines do that, at least to 
an extend (I think that was one of the selling features of Servo, later 
incorporated into Gecko). Complexity is definitely an issue, though.