GNU bug report logs - #56393
Actually fix the long lines display bug

Previous Next

Full log

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Gregory Heytings <gregory <at> heytings.org>
Cc: gerd.moellmann <at> gmail.com, larsi <at> gnus.org, 56393 <at> debbugs.gnu.org
Subject: Re: bug#56393: Actually fix the long lines display bug
Date: Mon, 18 Jul 2022 19:48:25 +0300

> Date: Mon, 18 Jul 2022 16:06:51 +0000
> From: Gregory Heytings <gregory <at> heytings.org>
> cc: gerd.moellmann <at> gmail.com, larsi <at> gnus.org, 56393 <at> debbugs.gnu.org
> 
> 
> And I just pushed an improved heuristic to detect long lines.  The code to 
> detect whether the buffer contains long lines will only be executed when 
> two or more characters have been added in the buffer since last redisplay, 
> which means that normal typing (that is, one character at a time) is now 
> entirely unaffected by that detection code.  On my laptop that code takes 
> only 1 ms in a 20 MiB large buffer, but that's still too much for my 
> taste.

Thanks, but couldn't we use the existing BUF_CHARS_MODIFF for that?

And I found a scenario in which redisplay is still very slow, as slow
as the master branch.  Here, try this:

  emacs -Q
  C-x C-f long-line.xml RET

Now, do NOT disable font-lock, and wait for Emacs to say "Valid" in
the mode line (to get nXML mode out of the way).  Then:

  M-x toggle-truncate-lines RET

Now simple cursor motion commands that use redisplay optimizations are
fast, but commands that cause more thorough redisplay are as slow as
on master.  As a simple example, try just "M-x" and wait until the
"M-x" prompt appears in the minibuffer -- here it takes much longer,
basically as long as the version on master.

Previous Next

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