GNU bug report logs - #56682
Fix the long lines font locking related slowdowns

Previous Next

Full log

Message #805 received at 56682 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Gregory Heytings <gregory <at> heytings.org>
Cc: 56682 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>,
 Dmitry Gutov <dgutov <at> yandex.ru>
Subject: Re: bug#56682: Fix the long lines font locking related slowdowns
Date: Wed, 03 Aug 2022 18:42:03 -0400

>> - 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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.