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

[Ihor Radchenko]

Eli Zaretskii <eliz@gnu.org> writes:

>> If might prove an okay experience, if the "outdated" part is within 
>> certain bounds. Like if the current buffer refreshes at 30/60fps, and 
>> the mode-line at 10/20fps, for example.
>
> That's not what was proposed.  The proposal was to do a
> "quick-and-dirty" layout first, and use the results if the "accurate"
> layout takes too long.  The quick-and-dirty layout can only be based
> on ignoring changes in fonts and disregarding images and stuff like
> that, so the screen lines will be wrong, and you will see them jump
> and/or rearrange after some delay, which could be some seconds.  Some
> browsers do that when they need to download images, and it always jars
> me when that happens.  Usually, I also lose the place where I was
> reading.
>
> I hope Emacs will never behave like that.

I can see how this can be annoying.
What about "quick-and-dirty" layout being "empty" window that is also
blocked for user interaction. (I am assuming that redisplay is
asynchronous here). Then, the user will be blocked from interacting
with a single problematic window being redisplayed, but could still work
with other windows/buffers without waiting for Emacs to "unhang".

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>