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

[Dmitry Gutov]

On 21/09/2023 12:39, Ihor Radchenko wrote:
> Po Lu<luangruo@yahoo.com>  writes:
>
> > > Then try leaning on C-n or C-p_after_  everything is already
> > > fontified.  You will still see that Emacs sometimes cannot keep up,
> > > especially if lines are not too short.
> > Long lines are, at worst, infrequently encountered in source code,
> > aren't they?  And our troubles with long lines are an algorithmic
> > impediment, which cannot be ameliorated merely by redisplaying each
> > window on a different CPU.
> 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.

> 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. But 
then the mode-line won't be refreshed at 60fps still, which some said is 
a good goal? (I tentatively agree).