GNU bug report logs -
#48170
next-line on large lines or images skips unexpectedly to next logical line
Previous Next
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 48170 in the body.
You can then email your comments to 48170 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#48170
; Package
emacs
.
(Sun, 02 May 2021 20:43:03 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Radon Rosborough <radon.neon <at> gmail.com>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Sun, 02 May 2021 20:43:03 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
Hi all,
I believe I've identified a bug in the implementation of
`line-move-partial' which occurs with certain pixelwise vertical
scroll positions.
The bug is that (under certain circumstances) when using `next-line'
on a long, visually-wrapped line, instead of moving to the next visual
line, point moves to the next logical line.
The "certain circumstances" are as follows:
1. Point is within a long logical line that is visually wrapped onto
at least two visual lines (the visual line containing point, and at
least one subsequent visual line).
2. The window line containing point is the bottom-most window line
that is fully visible.
3. The next window line is partially visible, and the pixel height of
the visible part of that line is less than the default line height (as
returned by `default-line-height').
This bug can be reproduced in either release 27.2 or the latest
development branch (83a915d3dfafd5f3d737afe1e13b75e4dd3aef96 of
2021-04-25). It does not require any configuration or third-party
packages (emacs -Q).
Because the default line height is fairly small (36px), it is
difficult to set up the pixelwise vertical scroll position
appropriately to trigger the bug, at least by default. Applying a face
with an increased :height property and increasing the text scaling
makes it easier, but I have confirmed that the bug reproduces even
with the default font face, given precise enough positioning.
I have uploaded a video demonstrating the behavior in the latest
development version of Emacs: https://youtu.be/dYMjgLSbGNE
I did some debugging in the course of identifying the conditions to
reproduce the bug, and the problematic behavior seems to come down to
something in the implementation of `line-move-partial'. There's a
conditional check (<= this-ypos (- dlh)) in `line-move-partial' that
gets triggered for certain combinations of window sizes and font
heights, and the code gated behind this check appears to be buggy,
resulting in the observed behavior.
I would be happy to get input about whether others can reproduce this
bug, and/or if you have ideas about the most appropriate way to fix or
work around it.
In case you're wondering how I ran into this issue: I am developing a
music player for Emacs which displays albums in a grid view for
selection, like iTunes. The implementation is to insert images via
`make-image', all in a single logical line, with appropriate margin
properties, and then let Emacs take care of the line-wrapping to form
a grid. Unfortunately, images are essentially very tall lines, which
makes it extremely easy to trigger this bug. The result is that when
you use `next-line' at the bottom of the window, point gets moved all
the way to the end of the buffer, which is no good.
In case it's relevant, I'm running GNOME under Pop!_OS.
Best,
Radon Rosborough
https://github.com/raxod502
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#48170
; Package
emacs
.
(Mon, 03 May 2021 17:03:01 GMT)
Full text and
rfc822 format available.
Message #8 received at 48170 <at> debbugs.gnu.org (full text, mbox):
> From: Radon Rosborough <radon.neon <at> gmail.com>
> Date: Sun, 2 May 2021 13:41:54 -0700
>
> The bug is that (under certain circumstances) when using `next-line'
> on a long, visually-wrapped line, instead of moving to the next visual
> line, point moves to the next logical line.
>
> The "certain circumstances" are as follows:
> 1. Point is within a long logical line that is visually wrapped onto
> at least two visual lines (the visual line containing point, and at
> least one subsequent visual line).
> 2. The window line containing point is the bottom-most window line
> that is fully visible.
> 3. The next window line is partially visible, and the pixel height of
> the visible part of that line is less than the default line height (as
> returned by `default-line-height').
Thanks. Preliminary analysis indicates that this use case was never
supported, since line-move-visual was introduced in Emacs 23.
This is somewhat tricky to debug (and %$#@! Edebug doesn't help), so
stay tuned.
> I did some debugging in the course of identifying the conditions to
> reproduce the bug, and the problematic behavior seems to come down to
> something in the implementation of `line-move-partial'. There's a
> conditional check (<= this-ypos (- dlh)) in `line-move-partial' that
> gets triggered for certain combinations of window sizes and font
> heights, and the code gated behind this check appears to be buggy,
> resulting in the observed behavior.
In my testing this part is never executed. And it shouldn't be,
because it handles the case where the window is vscrolled and the
current line starts above the top of the window. Which is not the
case here, at least not with the default frame size and window that is
not too small.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#48170
; Package
emacs
.
(Mon, 03 May 2021 17:19:01 GMT)
Full text and
rfc822 format available.
Message #11 received at 48170 <at> debbugs.gnu.org (full text, mbox):
> Date: Mon, 03 May 2021 20:02:00 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
> Cc: 48170 <at> debbugs.gnu.org
>
> Thanks. Preliminary analysis indicates that this use case was never
> supported, since line-move-visual was introduced in Emacs 23.
>
> This is somewhat tricky to debug (and %$#@! Edebug doesn't help), so
> stay tuned.
I have an idea for a solution, but to test it, I'd like to have a test
case with images, as in your original use case. Could you please
prepare a simple test case that uses small images in a continued line,
and post it here? TIA.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#48170
; Package
emacs
.
(Sun, 09 May 2021 17:41:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 48170 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Sure thing: you should be able to reproduce the issue simply by cloning
https://github.com/raxod502/bug48170-repro.git and evaluating the form in
code.el.
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#48170
; Package
emacs
.
(Thu, 13 May 2021 13:15:01 GMT)
Full text and
rfc822 format available.
Message #17 received at 48170 <at> debbugs.gnu.org (full text, mbox):
> From: Radon Rosborough <radon.neon <at> gmail.com>
> Date: Sun, 9 May 2021 10:40:07 -0700
> Cc: 48170 <at> debbugs.gnu.org
>
> Sure thing: you should be able to reproduce the issue simply by cloning
> https://github.com/raxod502/bug48170-repro.git and evaluating the form in code.el.
Thanks. Please try the latest master branch, I hope I fixed this.
Added tag(s) moreinfo.
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org
.
(Thu, 13 May 2021 13:24:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#48170
; Package
emacs
.
(Sat, 15 May 2021 23:36:01 GMT)
Full text and
rfc822 format available.
Message #22 received at 48170 <at> debbugs.gnu.org (full text, mbox):
> Please try the latest master branch, I hope I fixed this.
It sure looks fixed to me. Thanks so much, Eli!
Reply sent
to
Eli Zaretskii <eliz <at> gnu.org>
:
You have taken responsibility.
(Sun, 16 May 2021 04:16:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
Radon Rosborough <radon.neon <at> gmail.com>
:
bug acknowledged by developer.
(Sun, 16 May 2021 04:16:02 GMT)
Full text and
rfc822 format available.
Message #27 received at 48170-done <at> debbugs.gnu.org (full text, mbox):
> From: Radon Rosborough <radon.neon <at> gmail.com>
> Date: Sat, 15 May 2021 16:34:53 -0700
> Cc: 48170 <at> debbugs.gnu.org
>
> > Please try the latest master branch, I hope I fixed this.
>
> It sure looks fixed to me. Thanks so much, Eli!
Thanks for testing, I'm therefore closing this bug report.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Sun, 13 Jun 2021 11:24:07 GMT)
Full text and
rfc822 format available.
This bug report was last modified 2 years and 329 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.