Re: emacs rendering comparisson between emacs23 and emacs26.3

[Eli Zaretskii]

> From: Richard Stallman <address@hidden>
> Cc: address@hidden, address@hidden, address@hidden,
>       address@hidden
> Date: Tue, 07 Apr 2020 22:29:21 -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.
> 
>                                          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.)
> 
> Isn't that separate issue the issue we are talking about.

I'm not sure.  The text says "scan an entire buffer" and "the entire
part has to be continuously rescanned", which could be interpreted as
though this rescanning is the main culprit for the slowness.  I wanted
to point out that these aspects are not forced by the infrastructure
that causes the displayed text to be fontified just in time, but by
some of the major mode's fontification functions called by the
infrastructure.  It is IMO important to understand where to look for
code that needs to be sped up, to avoid wasting effort on optimizing
places that don't contribute significantly to the slowdown.

>                                             And frankly, what would we
>   > like Emacs to do instead?
> 
> It would scan only from the last open-paren-in-column-zero, as it did
> in the past.

That would produce incorrect display, as I explained later:

>                              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
> 
> I have a feeling there has been a change of topic here, but I can't be
> sure.

I surely didn't mean to change the topic.  If the argument was that
stopping considering the fontification at some arbitrary point in the
buffer will improve performance, my point was that it OTOH might
produce inaccurate display, which I consider not a good idea.