[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Dmitry Gutov
Subject: Re: Emacs design and architecture. How about copy-on-write?
Date: Thu, 21 Sep 2023 13:36:34 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0

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).

reply via email to

[Prev in Thread] Current Thread [Next in Thread]