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

Previous Next

Package: emacs;

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

Date: Tue, 5 Jul 2022 08:50:02 UTC

Severity: normal

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

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Gregory Heytings <gregory <at> heytings.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: gerd.moellmann <at> gmail.com, larsi <at> gnus.org, 56393 <at> debbugs.gnu.org
Subject: bug#56393: Actually fix the long lines display bug
Date: Mon, 18 Jul 2022 17:11:23 +0000
>
> Thanks, but couldn't we use the existing BUF_CHARS_MODIFF for that?
>

I'll have a look, thanks.

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

BTW, there is now a C-x x t binding for that.

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

Yes, it's a font locking issue.  Turn font-lock-mode off and the problem 
is gone.  As I said, I'll look at that later.




This bug report was last modified 3 years and 33 days ago.

Previous Next


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