bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#56682: Fix the long lines font locking related slowdowns


From: Stefan Monnier
Subject: bug#56682: Fix the long lines font locking related slowdowns
Date: Wed, 03 Aug 2022 18:42:03 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux)

>> - when they get a bug report with a locked narrowing because of long
>> lines, using `widen-unlock` naively is likely to lead to an immediate
>> performance problem, so it's unlikely they'll use it.
> When I read this, I thought you had a point, but there's a fallacy in your
> reasoning: using widen-unlock is in fact not likely to lead to an immediate
> performance problem.  The long-line-threshold limit is sufficiently high to
> never be reached in "normal" files, but nothing would happen if you cross
> that limit by a small amount, and nothing would even happen at twice or even
> thrice that limit.

That's a valid point.  A bit like Alan's bug report, where he gets
a regression for 10K-long lines where the performance would be tolerable.

> If a mode author gets a bug report that is caused by locked narrowing, there
> is something wrong in the way the mode fontifies the buffer.  There is no
> reason to require access the whole buffer to fontify a small chunk of that
> buffer.  IOW, using widen-unlock there is nearly always wrong (I add
> "nearly" to leave open the possibility that there might be an exception).

As I explained already, it's basically always wrong for a major mode's
font-lock rules to widen, regardless if the narrowing is due to
something like LLT or MMM-mode.

> This is becoming so litigious (you're now telling me that you're offended)
> that I start to believe that the right thing might in fact be to completely
> disable font locking in such buffers.  Would "no highlighting" be better
> than "occasional mis-highlighting" from your point of view?

I don't care about the mishighlighting and find the current behavior
perfectly acceptable from an end-user point of view.  I only care about
the extra enforcement done in C code without providing any mechanism to
circumvent it.  Especially since this discussion seems to suggest that
if I were to propose a patch that makes this locking a bit more "soft",
it might be rejected on the grounds that it opens the door to abuse, so
not only I strongly dislike this design but I can't even try and
improve it.


        Stefan






reply via email to

[Prev in Thread] Current Thread [Next in Thread]