GNU bug report logs - #59727
Problems with displaying long lines

Previous Next

To reply to this bug, email your comments to 59727 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

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

From: Juri Linkov <juri <at> linkov.net>
To: bug-gnu-emacs <at> gnu.org
Subject: Problems with displaying long lines
Date: Wed, 30 Nov 2022 19:46:37 +0200

[A new bug report from bug#56682]

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

Point moves correctly:

point=214748362 of 1135341900 (19%) column=214748361 Hscroll=214748321
point=214748363 of 1135341900 (19%) column=214748362 Hscroll=214748322
point=214748364 of 1135341900 (19%) column=214748363 Hscroll=214748323
point=214748365 of 1135341900 (19%) column=214748364 Hscroll=214748324
point=214748366 of 1135341900 (19%) column=214748365 Hscroll=214748325

but the cursor motion is not visible.

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

Maybe this limitation of auto-hscrolling should be documented?

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

Does pos-visible-in-window-p fail only on long lines?

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

Ok, therefore a new bug report.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Juri Linkov <juri <at> linkov.net>
Cc: 59727 <at> debbugs.gnu.org
Subject: Re: bug#59727: Problems with displaying long lines
Date: Wed, 30 Nov 2022 19:55:36 +0200

> From: Juri Linkov <juri <at> linkov.net>
> Date: Wed, 30 Nov 2022 19:46:37 +0200
> 
> [A new bug report from bug#56682]
> 
> >> 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?
> 
> Point moves correctly:

OK, then the new shortcuts in Emacs 29 for moving by columns in very long
and truncated lines do work reasonably.

> but the cursor motion is not visible.
> 
> > 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.
> 
> Maybe this limitation of auto-hscrolling should be documented?

We could document them, indeed.  But where? maybe in PROBLEMS?

> >> 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?
> 
> Does pos-visible-in-window-p fail only on long lines?

Not long, truncated ones.  It doesn't understand that positions that are to
the left or to the right of the viewport are not "visible".

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

From: Juri Linkov <juri <at> linkov.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 59727 <at> debbugs.gnu.org
Subject: Re: bug#59727: Problems with displaying long lines
Date: Wed, 30 Nov 2022 20:11:14 +0200

>> but the cursor motion is not visible.
>>
>> > 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.
>>
>> Maybe this limitation of auto-hscrolling should be documented?
>
> We could document them, indeed.  But where? maybe in PROBLEMS?

Not sure how to document this limitation because it still works
to some extent: when lines are not truncated, and point can be
moved to the end of a 1 GB buffer, then after toggling line truncation
while point is at the end of the buffer, cursor motion is shown
correctly with auto-hscrolling near the end of the buffer.

>> >> 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?
>>
>> Does pos-visible-in-window-p fail only on long lines?
>
> Not long, truncated ones.  It doesn't understand that positions that are to
> the left or to the right of the viewport are not "visible".

I don't know how it works but the docstring of pos-visible-in-window-p
says:

  If POS is only out of view because of horizontal scrolling, return non-nil.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: juri <at> linkov.net
Cc: 59727 <at> debbugs.gnu.org
Subject: Re: bug#59727: Problems with displaying long lines
Date: Wed, 30 Nov 2022 20:17:13 +0200

> Cc: 59727 <at> debbugs.gnu.org
> Date: Wed, 30 Nov 2022 19:55:36 +0200
> From: Eli Zaretskii <eliz <at> gnu.org>
> 
> > > 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.
> > 
> > Maybe this limitation of auto-hscrolling should be documented?
> 
> We could document them, indeed.  But where? maybe in PROBLEMS?

Or we could bite the bullet and lift the restriction: make current_x be a
ptrdiff_t, and then audit all the gazillion places where we make
calculations with the X coordinate and make sure we use ptrdiff_t there.
Probably not for emacs-29.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Juri Linkov <juri <at> linkov.net>
Cc: 59727 <at> debbugs.gnu.org
Subject: Re: bug#59727: Problems with displaying long lines
Date: Wed, 30 Nov 2022 20:38:14 +0200

> From: Juri Linkov <juri <at> linkov.net>
> Cc: 59727 <at> debbugs.gnu.org
> Date: Wed, 30 Nov 2022 20:11:14 +0200
> 
> >> Does pos-visible-in-window-p fail only on long lines?
> >
> > Not long, truncated ones.  It doesn't understand that positions that are to
> > the left or to the right of the viewport are not "visible".
> 
> I don't know how it works but the docstring of pos-visible-in-window-p
> says:
> 
>   If POS is only out of view because of horizontal scrolling, return non-nil.

That's what I said, no?

Previous Next

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