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

[Alan Mackenzie]

Hello, Eli.

On Wed, Aug 10, 2022 at 20:41:37 +0300, Eli Zaretskii wrote:
> > 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.

I suppose the problem here is differing notions of "absolute necessity".

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

OK, I think I see what you mean, now.

But I still think it's useful to make a distinction between looking at
(for example, the 17 ns per character that parse-partial-sexp takes) and
something like the fontification of a C declaration by
c-font-lock-declarations, which takes much, much longer.

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

I can't really see how that question follows on from the premiss, but
human brains are wired to detect patterns at a single glance in a way
that computers aren't, at least not yet.

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

Before the days of font-locking in editors, a standard problem was when a
comment didn't end where the user thought it did, for lack of a comment
ender.  There was a particular problem in Pascal (whose precise details
aren't that important) where an unclosed comment on the THEN branch of an
IF statement would swallow up the ELSE branch completely, leaving no
visible trace or syntactic error.

It's worth while being careful about strings and comments.

-- 
Alan Mackenzie (Nuremberg, Germany).