Re: How the long-lines "optimisation" breaks font locking.

[Eli Zaretskii <eliz@gnu.org>]

> Date: Wed, 3 Aug 2022 18:39:16 +0000
> From: Alan Mackenzie <acm@muc.de>
> 
> Hello Gregory and Emacs.
> 
> In the current master,
> (i) start emacs -Q
> (ii) C-x C-f ~/long-line.cc
> (iii) Enter the following into the buffer (3 lines):
> 
> char long_line[] = R"foo(
> 
> )foo"
> 
> (iv) Create a long line (> 10,000 characters) somehow and get it into
>   the kill ring.
> (v) On the blank line 2 in long-line.cc, C-y inserting the long line.
> 
> (vi) Note that there is now a long valid raw string in the buffer,
>   correctly fontified.
> (vii) Put point on a "o" in the foo on L3.  Delete the o
> (viii) Note that the opening delimiter of the raw string on L1 now has
>   warning-face.  This is correct.
> (ix) Undo this last change with C-_.
> (x) Note that the opening delimiter falsely retains the warning-face,
>   although it is now the opener of a validly terminated raw string.
>   This is a bug.
> 
> (xi) Insert a LF (or several, if needed) into the long line, separating
>   it into two or more lines, none of which is "long".
> (xii) Note that the raw string opener still has warning-face.  A bug.
> (xiii) Do M-x c++-mode.  This fails to initialise the fontification
>   correctly, leaving the warning-face where it no longer belongs.  This
>   is a bug.
> (xiv) Note that in the foregoing operations, sometimes an error message
>   appears in the echo area about the lack of an expected syntax-table
>   text property.  This is a bug.

I cannot reproduce this.  I don't see any warning-face in step viii,
and no problem in step x.

> I don't think it is improbable that a C++ hacker will create a long line
> in a raw string.  That this can cause permanent damage to the buffer's
> fontification doesn't seem a good thing.  That it is the recent
> "optimisation" for long lines which causes it can be seen by repeating
> the above steps, but with a line less than 10,000 characters long.  The
> fontification then behaves correctly.

Alan, please stop fighting this with impractical specially-concocted
scenarios.  No one in their right minds will need such long strings,
and if they do, and don't like whatever problems that causes (which I
cannot reproduce in the first place), they can enlarge the value of
long-line-threshold, or even make it nil.  Puff! problem solved.