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; 3+ 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] 3+ messages in thread

* bug#48170: next-line on large lines or images skips unexpectedly to next logical line
  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
  0 siblings, 1 reply; 3+ messages in thread
From: Eli Zaretskii @ 2021-05-03 17:02 UTC (permalink / raw)
  To: Radon Rosborough; +Cc: 48170

> 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.





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

* bug#48170: next-line on large lines or images skips unexpectedly to next logical line
  2021-05-03 17:02 ` Eli Zaretskii
@ 2021-05-03 17:17   ` Eli Zaretskii
  0 siblings, 0 replies; 3+ messages in thread
From: Eli Zaretskii @ 2021-05-03 17:17 UTC (permalink / raw)
  To: radon.neon; +Cc: 48170

> 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.





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

end of thread, other threads:[~2021-05-03 17:17 UTC | newest]

Thread overview: 3+ 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

unofficial mirror of bug-gnu-emacs@gnu.org 

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://yhetil.org/emacs-bugs/0 emacs-bugs/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 emacs-bugs emacs-bugs/ https://yhetil.org/emacs-bugs \
		bug-gnu-emacs@gnu.org
	public-inbox-index emacs-bugs

Example config snippet for mirrors.
Newsgroups are available over NNTP:
	nntp://news.yhetil.org/yhetil.emacs.bugs
	nntp://news.gmane.io/gmane.emacs.bugs


code repositories for project(s) associated with this inbox:

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

AGPL code for this site: git clone http://ou63pmih66umazou.onion/public-inbox.git