Re: emacs rendering comparisson between emacs23 and emacs26.3

[martin rudalics]

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

My text didn't say that _redisplay_ has to do that.  It talks about a
"consequence" and here the consequence is that jit-lock triggers an
eventual rescan of the rest of the buffer down to the part that is
displayed in another window.

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

It depends on what we consider a failure: I do not think that inserting
a "/*" in my window showing the top of my C buffer should cause the
window showing the bottom of my buffer consider everything part of a
comment starting at that "/*".  I think that the comment should stop at
the first paren in column zero after that "/*" even if that paren is
shown in the window showing the top of the buffer and even if that's
syntactically wrong (and hence the compiler would see it differently).

So what I would vote for in this case is that font-lock would specially
highlight the open paren that "stops seeing the comment as comment" so
the user is aware of the fact.  Would that be so hard to implement?
Even with a slight change in 'parse-partial-sexp' and 'syntax-ppss' that
would accompany it.  Optionally, by default turned off, so nobody who
wants the correct syntactic interpretation would be bothered.

martin