Re: New optimisations for long raw strings in C++ Mode.

[Eli Zaretskii <eliz@gnu.org>]

> Date: Wed, 10 Aug 2022 17:32:46 +0000
> Cc: gregory@heytings.org, larsi@gnus.org, emacs-devel@gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> > > > You seem to disagree with a major idea of the design of the Emacs
> > > > display engine.
> 
> > > I don't think I do.  I think you mean the idea of lazy fontification,
> > > though you haven't been specific.
> 
> > No, I mean the idea that redisplay processes only a small amount of
> > buffer text around the window.
> 
> I don't think such an idea is coherent, due to the lack of precision of
> the word "processes".  I understand that redisplay _fontifies_ only a
> small amount of buffer text.  However, it can get better results if it is
> free to _look_ at text anywhere in the buffer.

Think about the _idea_ of that: we want to process as little as
absolutely necessary for display.  It follows that every code we
invoke as part of that job should strive to do the same.

> You seem to be conflating "fontifying" with "looking at".  I don't think
> that's helpful.

I'm not talking about "looking at", I'm taking about processing.
fontification-functions rarely go to far places because they just want
to "look", they go there because they want to process text there,
possibly process all the text from there to window start.

> > > This is absolutely necessary correctly to fontify (long) strings and
> > > comments, for example.
> 
> > Only if you assume the most simplistic processing.
> 
> If you open a file in its middle (e.g., by desktop), and there's an open
> block comment there, you've got to look arbitrarily far back to detect
> that state.

Really?  Then please tell me how is it that we the humans can detect
incorrect fontifications even when shown partial strings and comments?
We know that fontifications are incorrect, and where strings or
comments start or end immediately, just after a single glance.  We
never need to go to BOB to find that out.