Re: Emacs design and architecture. How about copy-on-write?

[Eli Zaretskii]

> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: Po Lu <luangruo@yahoo.com>, Eli Zaretskii <eliz@gnu.org>, acm@muc.de,
>  incal@dataswamp.org, emacs-devel@gnu.org
> Date: Thu, 21 Sep 2023 10:48:25 +0000
> 
> Dmitry Gutov <dmitry@gutov.dev> writes:
> 
> >> I think that there is at least one way to address long lines using
> >> asynchronous redisplay - put a placeholder on the problematic line and
> >> continue calculating the actual rendering in the background instead.
> >> That will not force us to compromise between rendering time and
> >> accuracy, as we do now, with long-line-threshold.
> >
> > Until you're laid out the long line, you don't know which screen line it 
> > will finish at, or at which height specifically (it might have images, 
> > or taller text due to faces, etc). So you can't render the remainder of 
> > the buffer either.
> 
> What I had in mind is the processing to happen in two stages: (1)
> calculate "quick-and-dirty" layout; (2) start calculating "accurate"
> layout. If calculating "accurate" layout takes long time, go ahead and
> draw the "quick-and-dirty" version on the glass, while "accurate"
> version continues being computed in the background.
> 
> Of course, this threshold should be configurable.
> 
> >> Similar approach might be used to render mode lines - render a
> >> placeholder until it is fully calculated, keeping Emacs responsive.
> >
> > I hope by "placeholder" you mean the previous rendered image of it.
> 
> More precisely, what I had in mind is the old glyph matrix + some
> indication that the rendering is not up-to-date (like classic sand clock
> icon)

You are basically proposing us to provide broken, incorrect, and
outdated display in some cases.  That won't fly, so it's a
non-starter.