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

Previous Next

Package: emacs;

Reported by: Gregory Heytings <gregory <at> heytings.org>

Date: Thu, 21 Jul 2022 18:01:01 UTC

Severity: normal

Done: Gregory Heytings <gregory <at> heytings.org>

Bug is archived. No further changes may be made.

Full log


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

From: Gregory Heytings <gregory <at> heytings.org>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: 56682 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>,
 Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#56682: locked narrowing
Date: Wed, 30 Nov 2022 00:15:39 +0000
>> The result will be that the benchmark will report ~30ms both near BOB 
>> and near EOB. So the long-lines-threshold thingy adds a regression 
>> here.
>
> It's not a regression, it's the price we agreed to pay to detect whether 
> the buffer contains long lines.  That detection happens dynamically, to 
> catch cases when long lines are inserted in a buffer.
>

After looking at this closely, it turns out that the change in 1c837c42c2 
doesn't do what it was meant to do.  Sigh...  Dmitry, can you confirm that 
the following change fixes this?

diff --git a/src/xdisp.c b/src/xdisp.c
index b09aa6ec96..cdd6a7f5fe 100644
--- a/src/xdisp.c
+++ b/src/xdisp.c
@@ -19535,7 +19535,7 @@ redisplay_window (Lisp_Object window, bool just_this_one_p)
   /* Check whether the buffer to be displayed contains long lines.  */
   if (!NILP (Vlong_line_threshold)
       && !current_buffer->long_line_optimizations_p
-      && CHARS_MODIFF - CHARS_UNCHANGED_MODIFIED > 8)
+      && CHARS_MODIFF - UNCHANGED_MODIFIED > 8)
     {
       ptrdiff_t cur, next, found, max = 0, threshold;
       threshold = XFIXNUM (Vlong_line_threshold);




This bug report was last modified 2 years and 8 days ago.

Previous Next


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