unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
* bug#48170: next-line on large lines or images skips unexpectedly to next logical line
@ 2021-05-02 20:41 Radon Rosborough
  2021-05-03 17:02 ` Eli Zaretskii
  0 siblings, 1 reply; 7+ messages in thread
From: Radon Rosborough @ 2021-05-02 20:41 UTC (permalink / raw)
  To: 48170

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





^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2021-05-16  4:15 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-05-02 20:41 bug#48170: next-line on large lines or images skips unexpectedly to next logical line Radon Rosborough
2021-05-03 17:02 ` Eli Zaretskii
2021-05-03 17:17   ` Eli Zaretskii
2021-05-09 17:40     ` Radon Rosborough
2021-05-13 13:14       ` Eli Zaretskii
2021-05-15 23:34         ` Radon Rosborough
2021-05-16  4:15           ` Eli Zaretskii

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).