Subject: next-line on large lines or images skips unexpectedly to next logical line
From: Radon Rosborough <[email-masked]>
To: [email-masked]
Date: Sun, 2 May 2021 13:41:54 -0700
List-Id: <debbugs-submit.debbugs.gnu.org>

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