emacs-devel
[Top][All Lists]
Advanced

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

Re: emacs rendering comparisson between emacs23 and emacs26.3


From: Eli Zaretskii
Subject: Re: emacs rendering comparisson between emacs23 and emacs26.3
Date: Mon, 06 Apr 2020 16:21:21 +0300

> From: Richard Stallman <address@hidden>
> Cc: address@hidden, address@hidden, address@hidden, address@hidden
> Date: Sun, 05 Apr 2020 22:36:20 -0400
> 
>   > Recent Emacsen either ignore that variable or silently reset it to nil
>   > internally so it doesn't get into their way.  Their progmodes either
>   > always scan an entire buffer from its beginning or use some elaborate,
>   > fragile techniques to find such a top level position.  Moreover, our
>   > underlying mechanism for syntax highlighting always marks the entire
>   > rest of a buffer as dirty after every single editing change.  This has
>   > the consequence that that entire part has to be continuously rescanned
>   > when some of it is shown in another window.
> 
> Does anyone disagree with this specific factual claim?

I'm not sure what is "the claim" here, but I want to point out a small
inaccuracy: redisplay doesn't "continuously rescan the entire rest of
the buffer", it only rescans the part(s) shown in windows.  (It might
happen that some major mode's font-lock definitions end up rescanning
much more, but that's a separate issue.)  And frankly, what would we
like Emacs to do instead?  A change in a buffer can potentially affect
the fontification of the rest of the buffer, and I don't think we
would like Emacs to fail to update other windows showing the same
buffer -- that would be against Emacs's description as "real-time"
editor.



reply via email to

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