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

[Alan Mackenzie <acm@muc.de>]

Hello, Gregory.

On Tue, Aug 09, 2022 at 20:39:51 +0000, Gregory Heytings wrote:

> >>> But opening the resulting file with "emacs -Q" and then doing a `M->' 
> >>> now hangs Emacs, which it didn't use to do, I think?

> >> If you do (setq long-line-threshold nil), M-> is fast.  Only when you 
> >> omit it does Emacs hang.  Hmm.  It's meant to be the other way around, 
> >> isn't it?  ;-)

> > Yes.  I'm guessing there's some additional bug there.


> As has been discussed, CC Mode is, sadly, by design, incompatible with the 
> new feature .....

Er, actually, CC Mode has been around a tad longer than the new feature.

It would be more accurate to state that the new feature was, by design,
incompatible with existing software.  The new feature, by design, breaks
long-standing contracts in Emacs, namely that `widen', etc., work.

Of course, testing could have shown up this incompatibility at an early
stage, perhaps even leading to a solution.  A pity we didn't have more
thorough testing.

So, what do you intend to do about this incompatibility you have
introduced?  Anything?

> .... (and I wonder what the ";-)" above is supposed to convey).

The irony of a supposed optimisation causing software to hang.

> It insists on accessing the whole buffer, ....

There's no need to anthropomorphise.  A major mode accesses its buffer.
What will we have next!

> .... and doesn't downgrade gracefully when it can't.

Yeah, it depends on defined functionality working.  If only its
designers had been clever enough 20 years ago to foresee that parts of
Emacs would stop working as documented .....

> In this case, with emacs -Q, after M->, (jit-lock-fontify-now 999600
> 1001100) is called, which calls (c-font-lock-fontify-region 999600
> 1000034), which does (widen), and calls
> (font-lock-default-fontify-region 991200 1000034) because these
> (991200 and 1000034) are the bounds of the locked narrowing.  For some
> reason (which I don't have the patience to track down), because that
> (widen), which shouldn't be there in the first place,....

Yeah, it would be convenient for you if everybody followed your
(controversial) desires, rather than what's advertised in the Elisp
manual.  However, you knew before constructing your new feature that
major modes use widen, and went ahead and broke it anyway.  Still, I
suppose having rapid processing of monster buffers is more important
than longstanding software continuing to work, so that's all right,
then.

> .... doesn't do what the function expects it to do,
> font-lock-default-fontify-region never ends.

What do you intend to do about this?  Anything?

-- 
Alan Mackenzie (Nuremberg, Germany).