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

[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 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 Mackenzie (Nuremberg, Germany).