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

Previous Next

Full log

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Juri Linkov <juri <at> linkov.net>
Cc: 56682 <at> debbugs.gnu.org, gregory <at> heytings.org, monnier <at> iro.umontreal.ca,
 dgutov <at> yandex.ru
Subject: Re: bug#56682: locked narrowing
Date: Wed, 30 Nov 2022 19:34:28 +0200

> From: Juri Linkov <juri <at> linkov.net>
> Cc: Dmitry Gutov <dgutov <at> yandex.ru>,  56682 <at> debbugs.gnu.org,  Eli Zaretskii
>  <eliz <at> gnu.org>,  Stefan Monnier <monnier <at> iro.umontreal.ca>
> Date: Wed, 30 Nov 2022 18:34:15 +0200
> 
> 1. after 'M-g TAB' (move-to-column) to 214748364 or more,
>    the display is not updated anymore: moving point to the left
>    from this position shows the cursor, moving point to the right
>    has no visible effect.  Is it a hard limit in the display engine?
>    Its hex value is #xccccccc.

Sounds like a possible bug.  Does point move?  What does "C-x =" say about
point if you move beyond column 214748364?

If you window is auto-hscrolled as result, then there is indeed hard limit:
the X coordinate of a screen line is an 'int', so MAX_INT divided by the
pixel-width of your default font is as far as we can go.

> 2. after starting Isearch at a large column number,
>    Emacs hangs up indefinitely, e.g. with
>    'M-g TAB 10000000 RET C-s' then even C-g doesn't get out.
>    Debugging shows that the problem is in 'isearch-update'
>    where the call to 'pos-visible-in-window-group-p' doesn't return.
>    When this call is removed, the search is instantaneous.
>    (Optimizing lazy-highlight is a separate problem in bug#56815.)

I thought we agreed that calling pos-visible-in-window-p is not a good idea
in this situation, since it will always think any position is visible?

> PS: it seems these problems are not related to the locked narrowing,
> rather the locked narrowing helped to expose them, so maybe they
> should be reported in a new separate bug report?

It is unrelated, because handling lines that are both very long and
truncated on display uses a separate set of display shortcuts, and locked
narrowing has almost no effect on that.

Previous Next

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