[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: How the long-lines "optimisation" breaks font locking.
From: |
Eli Zaretskii |
Subject: |
Re: How the long-lines "optimisation" breaks font locking. |
Date: |
Wed, 03 Aug 2022 22:15:30 +0300 |
> 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.
- SOLVED: Re: How the long-lines "optimisation" breaks font locking., (continued)
- SOLVED: Re: How the long-lines "optimisation" breaks font locking., Eric S Fraga, 2022/08/04
- Re: SOLVED: Re: How the long-lines "optimisation" breaks font locking., Eric S Fraga, 2022/08/04
- Re: SOLVED: Re: How the long-lines "optimisation" breaks font locking., Stefan Kangas, 2022/08/04
- Re: SOLVED: Re: How the long-lines "optimisation" breaks font locking., Eric S Fraga, 2022/08/05
- Re: SOLVED: Re: How the long-lines "optimisation" breaks font locking., Eli Zaretskii, 2022/08/05
- Re: SOLVED: Re: How the long-lines "optimisation" breaks font locking., Eric S Fraga, 2022/08/05
- Re: SOLVED: Re: How the long-lines "optimisation" breaks font locking., Eric S Fraga, 2022/08/05
- Re: SOLVED: Re: How the long-lines "optimisation" breaks font locking., Tim Cross, 2022/08/05
- Re: SOLVED: Re: How the long-lines "optimisation" breaks font locking., Lars Ingebrigtsen, 2022/08/05
- Re: SOLVED: Re: How the long-lines "optimisation" breaks font locking., Fraga, Eric, 2022/08/08
Re: How the long-lines "optimisation" breaks font locking.,
Eli Zaretskii <=