From: Juri Linkov <juri@linkov.net>
To: 59727@debbugs.gnu.org
Subject: bug#59727: Problems with displaying long lines
Date: Wed, 30 Nov 2022 19:46:37 +0200 [thread overview]
Message-ID: <86zgc8e3nm.fsf@mail.linkov.net> (raw)
[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.
next reply other threads:[~2022-11-30 17:46 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-30 17:46 Juri Linkov [this message]
2022-11-30 17:55 ` bug#59727: Problems with displaying long lines Eli Zaretskii
2022-11-30 18:11 ` Juri Linkov
2022-11-30 18:38 ` Eli Zaretskii
2022-11-30 18:17 ` Eli Zaretskii
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=86zgc8e3nm.fsf@mail.linkov.net \
--to=juri@linkov.net \
--cc=59727@debbugs.gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.