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
> From: Radon Rosborough <radon.neon@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.
> Date: Mon, 03 May 2021 20:02:00 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 48170@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.
[-- Attachment #1: Type: text/plain, Size: 155 bytes --] 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. [-- Attachment #2: Type: text/html, Size: 239 bytes --]
> From: Radon Rosborough <radon.neon@gmail.com>
> Date: Sun, 9 May 2021 10:40:07 -0700
> Cc: 48170@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.
> Please try the latest master branch, I hope I fixed this.
It sure looks fixed to me. Thanks so much, Eli!
> From: Radon Rosborough <radon.neon@gmail.com>
> Date: Sat, 15 May 2021 16:34:53 -0700
> Cc: 48170@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.