bug#67604: Motion problems with inline images

bug#67604: Motion problems with inline images

[JD Smith]

[-- Attachment #1: Type: text/plain, Size: 1960 bytes --]

Following on from the recently fixed bug#67533, which related to incorrect pixel size measurements with inline images, one remaining issue, with that fix in place, relates to motion in buffers in visual line mode with inline images.  A video of the effect <https://gist.github.com/jdtsmith/ad765047a6afe20f353de573d8c07da9?permalink_comment_id=4780726#gistcomment-4780726> can be seen on the associated gist for bug#67533.

Here the issue is that next-line/forward-line/(vertical-motion 1) all skip from the Green inline SVG straight to the “JUMPS HERE” line, for certain frame widths (for me: 79 characters).  See reproduction code, below.  Depending on your font char size (mine is 7x14 pixels) this width may vary for you.  Note that multiple frame width produce the exact same wrapped appearance, but the motion bug shows up only for one of them.

There are other related phenomena, such as prev-line from an image at column 0 jumping to (near the) end of the previous screen line, but hopefully this is enough to identify the motion issue(s) at hand.

++++ 
(require 'svg)
(let ((buf "svg-file-motion-demo")
      (ims '(("red" 146 29)
	     ("green" 106 29)
	     ("blue" 151 29))))
  (with-current-buffer (get-buffer-create buf)
    (erase-buffer)
    (visual-line-mode 1)
    (insert "tellus.  $\\gamma(t) = \\log\\left(\\sqrt{\\tan(t)}\\right)$  Donec hendrerit tempor tellus.  $\\chi(y) = \\sqrt{\\frac{1}{\\log(y)}}$  Phasellus lacus.  $\\tau(t) = \\exp\\left(\\sqrt{\\exp(t)}\\right)$  Curabitur lacinia pulvinar nibh.
JUMPS HERE")
    (goto-char (point-min))
    (while  (re-search-forward (rx ?$ (* (not ?$)) ?$) nil t)
      (let* ((ov (make-overlay (match-beginning 0) (match-end 0)))
	     (im (pop ims))
	     (svg (svg-create (nth 1 im) (nth 2 im))))
	(svg-rectangle svg 0 0 (nth 1 im) (nth 2 im) :fill-color (car im))
	(overlay-put ov 'display (svg-image svg :ascent 'center)))))
  (pop-to-buffer buf))
++++


[-- Attachment #2: Type: text/html, Size: 3252 bytes --]

bug#67604: Motion problems with inline images

[Eli Zaretskii]

> From: JD Smith <jdtsmith@gmail.com>
> Date: Sun, 3 Dec 2023 11:54:27 -0500
> 
> Following on from the recently fixed bug#67533, which related to incorrect pixel size measurements
> with inline images, one remaining issue, with that fix in place, relates to motion in buffers in visual line
> mode with inline images.  A video of the effect can be seen on the associated gist for bug#67533.
> 
> Here the issue is that next-line/forward-line/(vertical-motion 1) all skip from the Green inline SVG
> straight to the “JUMPS HERE” line, for certain frame widths (for me: 79 characters).  See
> reproduction code, below.  Depending on your font char size (mine is 7x14 pixels) this width may
> vary for you.  Note that multiple frame width produce the exact same wrapped appearance, but the
> motion bug shows up only for one of them.

I tried different frame widths, but couldn't reproduce the problem.
Not with the latest master branch, anyway, where I recently installed
the changes from bug#67533.

If someone can tell what frame width and default font height trigger
the problem, I will try to reproduce with those sizes.

bug#67604: Motion problems with inline images

[JD Smith]

[-- Attachment #1: Type: text/plain, Size: 2889 bytes --]

> On Dec 3, 2023, at 12:11 PM, Eli Zaretskii <eliz@gnu.org> wrote:
> 
>> From: JD Smith <jdtsmith@gmail.com>
>> Date: Sun, 3 Dec 2023 11:54:27 -0500
>> 
>> Following on from the recently fixed bug#67533, which related to incorrect pixel size measurements
>> with inline images, one remaining issue, with that fix in place, relates to motion in buffers in visual line
>> mode with inline images.  A video of the effect can be seen on the associated gist for bug#67533.
>> 
>> Here the issue is that next-line/forward-line/(vertical-motion 1) all skip from the Green inline SVG
>> straight to the “JUMPS HERE” line, for certain frame widths (for me: 79 characters).  See
>> reproduction code, below.  Depending on your font char size (mine is 7x14 pixels) this width may
>> vary for you.  Note that multiple frame width produce the exact same wrapped appearance, but the
>> motion bug shows up only for one of them.
> 
> I tried different frame widths, but couldn't reproduce the problem.
> Not with the latest master branch, anyway, where I recently installed
> the changes from bug#67533.
> 
> If someone can tell what frame width and default font height trigger
> the problem, I will try to reproduce with those sizes.

I just compiled a fresh NS build from master with your bug#67533 fix.  It triggers the skip-a-line bug for me, from emacs -q at frame-width=79.  But I can also confirm, it is font size dependent, likely occurring with only a precise combination of pixel sizes.  

Here’s an easy way to find it with your font, using the attached command:

Run the let-form mentioned in my initial message.
Resize the frame width down until the green image first moves to the beginning of a visual line (80 chars, for me).
Resize down one more column *without causing further wrap* (79 chars for me).
In the svg-file-motion-demo buffer, execute M-x my/find-skip-bug.
It should report the pixel width needed for the red SVG image on the first line to trigger the bug, and leave the demo buffer in that state.
Hitting down twice from (point-min) should land on JUMPS HERE, bypassing the stub line “pulvinar nibh".

++++

(defun my/find-skip-bug ()
  (interactive)
  (goto-char (point-min))
  (let* ((ov (car (overlays-at 10)))
	 (w 146)
	 (h 29)
	 (wc (frame-char-width))
	 (res
	  (cl-loop
	   for off from (- (- wc 2)) to (1- wc)
	   for sw = (+ w off)
	   for svg = (svg-create sw h) do
	   (message "Checking with red image width %d" sw)
	   (svg-rectangle svg 0 0 sw h :fill-color "red")
	   (overlay-put ov 'display (svg-image svg :ascent 'center))
	   if (save-excursion
		(next-line) (next-line)
		(beginning-of-visual-line)
		(looking-at "JUMPS HERE"))
	   return off
	   finally return nil)))
    (if res (message "Found Bug at offset %d = %d pixels" res (+ w res))
      (message "Did not find Bug"))))
  


[-- Attachment #2: Type: text/html, Size: 5149 bytes --]

bug#67604: Motion problems with inline images

[Eli Zaretskii]

> From: JD Smith <jdtsmith@gmail.com>
> Date: Sun, 3 Dec 2023 15:46:38 -0500
> Cc: 67604@debbugs.gnu.org
> 
> * Run the let-form mentioned in my initial message.
> * Resize the frame width down until the green image first moves to the beginning of a visual line (80
>  chars, for me).
> * Resize down one more column *without causing further wrap* (79 chars for me).
> * In the svg-file-motion-demo buffer, execute M-x my/find-skip-bug.
> * It should report the pixel width needed for the red SVG image on the first line to trigger the bug,
>  and leave the demo buffer in that state.

Instead of reporting the size, it says "Did not find Bug".

bug#67604: Motion problems with inline images

[JD Smith]

> On Dec 4, 2023, at 8:16 AM, Eli Zaretskii <eliz@gnu.org> wrote:
> 
>> From: JD Smith <jdtsmith@gmail.com>
>> Date: Sun, 3 Dec 2023 15:46:38 -0500
>> Cc: 67604@debbugs.gnu.org
>> 
>> * Run the let-form mentioned in my initial message.
>> * Resize the frame width down until the green image first moves to the beginning of a visual line (80
>> chars, for me).
>> * Resize down one more column *without causing further wrap* (79 chars for me).
>> * In the svg-file-motion-demo buffer, execute M-x my/find-skip-bug.
>> * It should report the pixel width needed for the red SVG image on the first line to trigger the bug,
>> and leave the demo buffer in that state.
> 
> Instead of reporting the size, it says "Did not find Bug”.

Try increasing/decreasing width by one or two columns and repeating.  Note that if you go too far, you’ll get a false positive report when the green SVG wraps back to line 1. 

bug#67604: Motion problems with inline images

[Eli Zaretskii]

> From: JD Smith <jdtsmith@gmail.com>
> Date: Mon, 4 Dec 2023 09:10:01 -0500
> Cc: 67604@debbugs.gnu.org
> 
> 
> 
> > On Dec 4, 2023, at 8:16 AM, Eli Zaretskii <eliz@gnu.org> wrote:
> > 
> >> From: JD Smith <jdtsmith@gmail.com>
> >> Date: Sun, 3 Dec 2023 15:46:38 -0500
> >> Cc: 67604@debbugs.gnu.org
> >> 
> >> * Run the let-form mentioned in my initial message.
> >> * Resize the frame width down until the green image first moves to the beginning of a visual line (80
> >> chars, for me).
> >> * Resize down one more column *without causing further wrap* (79 chars for me).
> >> * In the svg-file-motion-demo buffer, execute M-x my/find-skip-bug.
> >> * It should report the pixel width needed for the red SVG image on the first line to trigger the bug,
> >> and leave the demo buffer in that state.
> > 
> > Instead of reporting the size, it says "Did not find Bug”.
> 
> Try increasing/decreasing width by one or two columns and repeating.  Note that if you go too far, you’ll get a false positive report when the green SVG wraps back to line 1. 

Sorry, still no cigar.

bug#67604: Motion problems with inline images

[JD Smith]

[-- Attachment #1: Type: text/plain, Size: 224 bytes --]

Strange.  Can I ask your (frame-char-width) and (frame-char-height)?  I haven’t yet found a font or size where the bug isn’t discoverable.  Usually at multiple frame widths.

Just confirming your buffer looks like:


[-- Attachment #2: PastedGraphic-1.png --]
[-- Type: image/png, Size: 135585 bytes --]

[-- Attachment #3: Type: text/plain, Size: 1808 bytes --]



And that *Messages* includes something like:

Checking with red image width 139
Checking with red image width 140
Checking with red image width 141
Checking with red image width 142
Checking with red image width 143
Checking with red image width 144
Checking with red image width 145
Checking with red image width 146
Checking with red image width 147
Checking with red image width 148
Checking with red image width 149
Checking with red image width 150
Checking with red image width 151
Checking with red image width 152
Checking with red image width 153
Found Bug at offset 7 = 153 pixels

> On Dec 4, 2023, at 9:17 AM, Eli Zaretskii <eliz@gnu.org> wrote:
> 
>> From: JD Smith <jdtsmith@gmail.com>
>> Date: Mon, 4 Dec 2023 09:10:01 -0500
>> Cc: 67604@debbugs.gnu.org
>> 
>> 
>> 
>>> On Dec 4, 2023, at 8:16 AM, Eli Zaretskii <eliz@gnu.org> wrote:
>>> 
>>>> From: JD Smith <jdtsmith@gmail.com>
>>>> Date: Sun, 3 Dec 2023 15:46:38 -0500
>>>> Cc: 67604@debbugs.gnu.org
>>>> 
>>>> * Run the let-form mentioned in my initial message.
>>>> * Resize the frame width down until the green image first moves to the beginning of a visual line (80
>>>> chars, for me).
>>>> * Resize down one more column *without causing further wrap* (79 chars for me).
>>>> * In the svg-file-motion-demo buffer, execute M-x my/find-skip-bug.
>>>> * It should report the pixel width needed for the red SVG image on the first line to trigger the bug,
>>>> and leave the demo buffer in that state.
>>> 
>>> Instead of reporting the size, it says "Did not find Bug”.
>> 
>> Try increasing/decreasing width by one or two columns and repeating.  Note that if you go too far, you’ll get a false positive report when the green SVG wraps back to line 1.
> 
> Sorry, still no cigar.

bug#67604: Motion problems with inline images

[Eli Zaretskii]

> From: JD Smith <jdtsmith@gmail.com>
> Date: Mon, 4 Dec 2023 09:25:16 -0500
> Cc: 67604@debbugs.gnu.org
> 
> Strange.  Can I ask your (frame-char-width) and (frame-char-height)?  I haven’t yet found a font or size where the bug isn’t discoverable.  Usually at multiple frame widths.

width = 8, height = 16

I also tried 7 and 15, also without success.

> Just confirming your buffer looks like:

Yes.

bug#67604: Motion problems with inline images

[JD Smith]

> On Dec 4, 2023, at 9:37 AM, Eli Zaretskii <eliz@gnu.org> wrote:
> 
>> From: JD Smith <jdtsmith@gmail.com>
>> Date: Mon, 4 Dec 2023 09:25:16 -0500
>> Cc: 67604@debbugs.gnu.org
>> 
>> Strange.  Can I ask your (frame-char-width) and (frame-char-height)?  I haven’t yet found a font or size where the bug isn’t discoverable.  Usually at multiple frame widths.
> 
> width = 8, height = 16
> 
> I also tried 7 and 15, also without success.


Wonders never cease.  I just picked an 8x16 font and it worked fine, finding the bug at offset=2 (i.e. red svg=148 pixels wide). This was using the build from this morning with your recent xdisp.c fix.  To be sure we’re on the same page, I’ve included again the test code below.

My version info: GNU Emacs 30.0.50 (build 5, aarch64-apple-darwin23.1.0, NS appkit-2487.20 Version 14.1.2 (Build 23B92)) of 2023-12-04.   

I suppose this motion bug could be version-dependent?  If anyone else can confirm this on NS or other builds that would be most helpful.

One other scraping-the-barrel's-bottom idea: I’ve found before that (frame-char-width) when called “too early” yields incorrect/missing results; are you running the code interactively, or via a batch style setup?  Do you see a nice range of “Check with red image width …” messages?

++++
(require 'svg)
(let ((buf "svg-file-motion-demo")
      (ims '(("red" 146 29) ; 146 start
	     ("green" 108 29) ; 108 start
	     ("blue" 151 29))))
  (with-current-buffer (get-buffer-create buf)
    (erase-buffer)
    (visual-line-mode 1)
    (insert "tellus.  $\\gamma(t) = \\log\\left(\\sqrt{\\tan(t)}\\right)$  Donec hendrerit tempor tellus.  $\\chi(y) = \\sqrt{\\frac{1}{\\log(y)}}$  Phasellus lacus.  $\\tau(t) = \\exp\\left(\\sqrt{\\exp(t)}\\right)$  Curabitur lacinia pulvinar nibh.
JUMPS HERE")
    (goto-char (point-min))
    (while  (re-search-forward (rx ?$ (* (not ?$)) ?$) nil t)
      (let* ((ov (make-overlay (match-beginning 0) (match-end 0)))
	     (im (pop ims))
	     (svg (svg-create (nth 1 im) (nth 2 im))))
	(svg-rectangle svg 0 0 (nth 1 im) (nth 2 im) :fill-color (car im))
	(overlay-put ov 'display (svg-image svg :ascent 'center)))))
  (pop-to-buffer buf))

(defun my/find-skip-bug ()
  (interactive)
  (goto-char (point-min))
  (let* ((ov (car (overlays-at 10)))
	 (w 146)
	 (h 29)
	 (wc (frame-char-width))
	 (res
	  (cl-loop
	   for off from (- (- wc 2)) to (1- wc)
	   for sw = (+ w off)
	   for svg = (svg-create sw h) do
	   (message "Checking with red image width %d" sw)
	   (svg-rectangle svg 0 0 sw h :fill-color "red")
	   (overlay-put ov 'display (svg-image svg :ascent 'center))
	   if (save-excursion
		(next-line) (next-line)
		(beginning-of-visual-line)
		(looking-at "JUMPS HERE"))
	   return off
	   finally return nil)))
    (if res (message "Found Bug at offset %d = %d pixels" res (+ w res))
      (message "Did not find Bug"))))

bug#67604: Motion problems with inline images

[Eli Zaretskii]

> From: JD Smith <jdtsmith@gmail.com>
> Date: Mon, 4 Dec 2023 12:44:45 -0500
> Cc: 67604@debbugs.gnu.org
> 
> Wonders never cease.  I just picked an 8x16 font and it worked fine, finding the bug at offset=2 (i.e. red svg=148 pixels wide). This was using the build from this morning with your recent xdisp.c fix.  To be sure we’re on the same page, I’ve included again the test code below.

Now I run it and I get

   Found Bug at offset -6 = 140 pixels

but the problem with cursor jumping to "JUMPS HERE" still doesn't
happen.

> One other scraping-the-barrel's-bottom idea: I’ve found before that (frame-char-width) when called “too early” yields incorrect/missing results; are you running the code interactively, or via a batch style setup?  Do you see a nice range of “Check with red image width …” messages?

I'm running the code interactively, and I do see those "Check..."
messages (mainly in *Messages*, as they are very quickly replaced by
the finishing message).

bug#67604: Motion problems with inline images

[JD Smith]

> On Dec 4, 2023, at 1:20 PM, Eli Zaretskii <eliz@gnu.org> wrote:
> 
>> From: JD Smith <jdtsmith@gmail.com>
>> Date: Mon, 4 Dec 2023 12:44:45 -0500
>> Cc: 67604@debbugs.gnu.org
>> 
>> Wonders never cease.  I just picked an 8x16 font and it worked fine, finding the bug at offset=2 (i.e. red svg=148 pixels wide). This was using the build from this morning with your recent xdisp.c fix.  To be sure we’re on the same page, I’ve included again the test code below.
> 
> Now I run it and I get
> 
>   Found Bug at offset -6 = 140 pixels
> 
> but the problem with cursor jumping to "JUMPS HERE" still doesn't
> happen.


OK great.  Is it possible at offset = -6 = 140 pixels the green image has wrapped back onto line 1?  That’s a “false positive” bug.  The layout after my/find-skip-bug has found the magic width must look as in my prior screenshot (with green image at the beginning of screen line 2) or it’s not a real bug.

If it does look correct, from (point-min), any pair of next-line or (vertical-motion 1), should bypass scene line 3 = "pulvinar nibh" and land on screen line 4 = "JUMPS HERE", as that’s the literal test find-skip-bug performs!

bug#67604: Motion problems with inline images

[Eli Zaretskii]

> From: JD Smith <jdtsmith@gmail.com>
> Date: Mon, 4 Dec 2023 14:16:10 -0500
> Cc: 67604@debbugs.gnu.org
> 
> > Now I run it and I get
> > 
> >   Found Bug at offset -6 = 140 pixels
> > 
> > but the problem with cursor jumping to "JUMPS HERE" still doesn't
> > happen.
> 
> 
> OK great.  Is it possible at offset = -6 = 140 pixels the green image has wrapped back onto line 1?  That’s a “false positive” bug.  The layout after my/find-skip-bug has found the magic width must look as in my prior screenshot (with green image at the beginning of screen line 2) or it’s not a real bug.

No, it looks with the green image at the visual end of a screen line.

> If it does look correct, from (point-min), any pair of next-line or
> (vertical-motion 1), should bypass scene line 3 = "pulvinar nibh"
> and land on screen line 4 = "JUMPS HERE",

It doesn't.  It works as expected.

bug#67604: Motion problems with inline images

[JD Smith]

> On Dec 4, 2023, at 2:38 PM, Eli Zaretskii <eliz@gnu.org> wrote:
> 
>> From: JD Smith <jdtsmith@gmail.com>
>> Date: Mon, 4 Dec 2023 14:16:10 -0500
>> Cc: 67604@debbugs.gnu.org
>> 
>>> Now I run it and I get
>>> 
>>>  Found Bug at offset -6 = 140 pixels
>>> 
>>> but the problem with cursor jumping to "JUMPS HERE" still doesn't
>>> happen.
>> 
>> 
>> OK great.  Is it possible at offset = -6 = 140 pixels the green image has wrapped back onto line 1?  That’s a “false positive” bug.  The layout after my/find-skip-bug has found the magic width must look as in my prior screenshot (with green image at the beginning of screen line 2) or it’s not a real bug.
> 
> No, it looks with the green image at the visual end of a screen line.

Before or after the test?  If before the test, you haven’t tried this, please resize the frame until the green image wraps to visual line 2, then reduce width by one column more.

bug#67604: Motion problems with inline images

[Eli Zaretskii]

> From: JD Smith <jdtsmith@gmail.com>
> Date: Mon, 4 Dec 2023 16:05:56 -0500
> Cc: 67604@debbugs.gnu.org
> 
> >> OK great.  Is it possible at offset = -6 = 140 pixels the green image has wrapped back onto line 1?  That’s a “false positive” bug.  The layout after my/find-skip-bug has found the magic width must look as in my prior screenshot (with green image at the beginning of screen line 2) or it’s not a real bug.
> > 
> > No, it looks with the green image at the visual end of a screen line.
> 
> Before or after the test?

After the test.

bug#67604: Motion problems with inline images

[JD Smith]

> On Dec 4, 2023, at 10:24 PM, Eli Zaretskii <eliz@gnu.org> wrote:
> 
>> From: JD Smith <jdtsmith@gmail.com>
>> Date: Mon, 4 Dec 2023 16:05:56 -0500
>> Cc: 67604@debbugs.gnu.org
>> 
>>>> OK great.  Is it possible at offset = -6 = 140 pixels the green image has wrapped back onto line 1?  That’s a “false positive” bug.  The layout after my/find-skip-bug has found the magic width must look as in my prior screenshot (with green image at the beginning of screen line 2) or it’s not a real bug.
>>> 
>>> No, it looks with the green image at the visual end of a screen line.
>> 
>> Before or after the test?
> 
> After the test.

OK, so this was likely a false positive then.  I’m out of ideas.  Maybe Windows is magically immune.

For me both NS and Mac builds with your most recent xdisp.c fixes exhibit the same motion issue.  Do you have anyone you can call in to try the simple test on another build?

Thanks.

bug#67604: Motion problems with inline images

[Eli Zaretskii]

> From: JD Smith <jdtsmith@gmail.com>
> Date: Tue, 5 Dec 2023 18:06:41 -0500
> Cc: 67604@debbugs.gnu.org
> 
> >> Before or after the test?
> > 
> > After the test.
> 
> OK, so this was likely a false positive then.  I’m out of ideas.  Maybe Windows is magically immune.

Unlikely.  More likely is that we need some specific metrics of the
displayed stuff to see the problem (which is therefore very rare).

> For me both NS and Mac builds with your most recent xdisp.c fixes exhibit the same motion issue.  Do you have anyone you can call in to try the simple test on another build?

Not really, no.  But reproducing the problem is just a step towards
debugging it, so the alternative is for you to step through next-line
and its subroutines (or in C through vertical-motion) and tell what
happens there, and preferably also why.  It isn't like I'm the only
one who should be able to read the code and understand where it fails.

bug#67604: Motion problems with inline images

[JD Smith]

[-- Attachment #1: Type: text/plain, Size: 1594 bytes --]



> On Dec 5, 2023, at 10:31 PM, Eli Zaretskii <eliz@gnu.org> wrote:
> 
>> From: JD Smith <jdtsmith@gmail.com>
>> Date: Tue, 5 Dec 2023 18:06:41 -0500
>> Cc: 67604@debbugs.gnu.org
>> 
>>>> Before or after the test?
>>> 
>>> After the test.
>> 
>> OK, so this was likely a false positive then.  I’m out of ideas.  Maybe Windows is magically immune.
> 
> Unlikely.  More likely is that we need some specific metrics of the
> displayed stuff to see the problem (which is therefore very rare).
> 
>> For me both NS and Mac builds with your most recent xdisp.c fixes exhibit the same motion issue.  Do you have anyone you can call in to try the simple test on another build?
> 
> Not really, no.  But reproducing the problem is just a step towards
> debugging it, so the alternative is for you to step through next-line
> and its subroutines

I stepped through next-line and subroutines via edebug and landed via line-move-visual on:

(vertical-motion  (cons (or goal-column
				     (if (consp temporary-goal-column)
					 (car temporary-goal-column)
				       temporary-goal-column))
				 arg))

So vertical-motion is where all fingers point.

> It isn't like I'm the only
> one who should be able to read the code and understand where it fails.

I agree with that, but unfortunately am not setup for it here and have next to no familiarity with Emacs’ C code.  I’m sorry I can’t be of more help.  But similar to how you were unable to work with dvisvgm and other packages, I don’t have access to gdb, as it is not supported on my architecture.


[-- Attachment #2: Type: text/html, Size: 2778 bytes --]

bug#67604: Motion problems with inline images

[Eli Zaretskii]

> From: JD Smith <jdtsmith@gmail.com>
> Date: Tue, 5 Dec 2023 23:33:42 -0500
> Cc: 67604@debbugs.gnu.org
> 
>  Not really, no.  But reproducing the problem is just a step towards
>  debugging it, so the alternative is for you to step through next-line
>  and its subroutines
> 
> I stepped through next-line and subroutines via edebug and landed via line-move-visual on:
> 
>  (vertical-motion  (cons (or goal-column
>      (if (consp temporary-goal-column)
>  (car temporary-goal-column)
>        temporary-goal-column))
>  arg))
> 
> So vertical-motion is where all fingers point.

Did you verify that goal-column and temporary-goal-column have correct
values in the case where the problem happens?

>  It isn't like I'm the only
>  one who should be able to read the code and understand where it fails.
> 
> I agree with that, but unfortunately am not setup for it here and have next to no familiarity with Emacs’
> C code.  I’m sorry I can’t be of more help.  But similar to how you were unable to work with dvisvgm
> and other packages, I don’t have access to gdb, as it is not supported on my architecture.

If someone can reproduce and debug the problem on a system other than
macOS, that would be some progress.  (If the problem is specific to
macOS, it is much less interesting, at least to me, since the display
code on macOS behaves differently in significant ways, and because
macOS is in general an idiosyncratic platform.)

bug#67604: Motion problems with inline images

[JD Smith]

[-- Attachment #1: Type: text/plain, Size: 2933 bytes --]



> On Dec 6, 2023, at 7:25 AM, Eli Zaretskii <eliz@gnu.org> wrote:
> 
>> From: JD Smith <jdtsmith@gmail.com>
>> Date: Tue, 5 Dec 2023 23:33:42 -0500
>> Cc: 67604@debbugs.gnu.org
>> 
>> Not really, no.  But reproducing the problem is just a step towards
>> debugging it, so the alternative is for you to step through next-line
>> and its subroutines
>> 
>> I stepped through next-line and subroutines via edebug and landed via line-move-visual on:
>> 
>> (vertical-motion  (cons (or goal-column
>>     (if (consp temporary-goal-column)
>> (car temporary-goal-column)
>>       temporary-goal-column))
>> arg))
>> 
>> So vertical-motion is where all fingers point.
> 
> Did you verify that goal-column and temporary-goal-column have correct
> values in the case where the problem happens?

Yes.  Sometimes the temporary-goal-column is 0 (if I C-a on a text line) or sometimes a fractional number like 66.5 or similar if I start my downward movement by first C-a’ing on the green image line.  In both cases the short screen line #3 line is skipped.

>> It isn't like I'm the only
>> one who should be able to read the code and understand where it fails.
>> 
>> I agree with that, but unfortunately am not setup for it here and have next to no familiarity with Emacs’
>> C code.  I’m sorry I can’t be of more help.  But similar to how you were unable to work with dvisvgm
>> and other packages, I don’t have access to gdb, as it is not supported on my architecture.
> 
> If someone can reproduce and debug the problem on a system other than
> macOS, that would be some progress.  (If the problem is specific to
> macOS, it is much less interesting, at least to me, since the display
> code on macOS behaves differently in significant ways, and because
> macOS is in general an idiosyncratic platform.)

I have made progress.  I built master on a remote Linux server and ran it via X forwarding.  With an 8x17 font, the bug is found at offset 2 = 148 pixel width of the red SVG, for the specific frame-width = 74.   I verified that (vertical-motion 1) causes the same line-skip error, when starting from the green image.  

This makes me think that your difficulty reproducing the bug on your system may result from a miscommunication.  To be sure, I’ve recorded a session of me (re-)discovering the bug at this comment <https://gist.github.com/jdtsmith/914c9f44ed5f5394e4ec188b00b09b47?permalink_comment_id=4784608#gistcomment-4784608>.  Hopefully that’s useful.  

If not, I did the build on my Linux server with debug options, and can run over gdb. If you can give me a simple recipe for where I should break and what I should look at, I’m happy to try.  But I suspect it will be 25x more efficient for you to have a look if you can reproduce.

Re MacOS, I’m surprised you wouldn’t say that Windows is similarly an idiosyncratic system for display and other purposes.

[-- Attachment #2: Type: text/html, Size: 9449 bytes --]

bug#67604: Motion problems with inline images

[JD Smith]

> On Dec 5, 2023, at 10:31 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>> OK, so this was likely a false positive then.  I’m out of ideas.  Maybe Windows is magically immune.
> 
> Unlikely.  More likely is that we need some specific metrics of the
> displayed stuff to see the problem (which is therefore very rare).

I agree with this sentiment: it does seem to require special tuning to reveal itself.  I wanted to check to see if you had received my news that I reproduced the line-skip motion bug on a GNU/Linux system.  That would seem to confirm it’s a general issue with the display/motion code dealing with inline images.  Let me know if I can produce anything else to help with this one.  Thanks.

bug#67604: Motion problems with inline images

[Eli Zaretskii]

> From: JD Smith <jdtsmith@gmail.com>
> Date: Mon, 11 Dec 2023 14:06:38 -0500
> Cc: 67604@debbugs.gnu.org
> 
> 
> 
> > On Dec 5, 2023, at 10:31 PM, Eli Zaretskii <eliz@gnu.org> wrote:
> >> OK, so this was likely a false positive then.  I’m out of ideas.  Maybe Windows is magically immune.
> > 
> > Unlikely.  More likely is that we need some specific metrics of the
> > displayed stuff to see the problem (which is therefore very rare).
> 
> I agree with this sentiment: it does seem to require special tuning to reveal itself.  I wanted to check to see if you had received my news that I reproduced the line-skip motion bug on a GNU/Linux system.  That would seem to confirm it’s a general issue with the display/motion code dealing with inline images.  Let me know if I can produce anything else to help with this one.  Thanks.

I've eventually succeeded in reproducing it.  I will get to it when I
have time; however, with the current tempest on emacs-devel and other
urgent issues, I don't know when will that be.

bug#67604: Motion problems with inline images

[JD Smith]

> On Dec 11, 2023, at 2:44 PM, Eli Zaretskii <eliz@gnu.org> wrote:
> 
>> From: JD Smith <jdtsmith@gmail.com>
>> Date: Mon, 11 Dec 2023 14:06:38 -0500
>> Cc: 67604@debbugs.gnu.org
>> 
>> 
>> 
>>> On Dec 5, 2023, at 10:31 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>>>> OK, so this was likely a false positive then.  I’m out of ideas.  Maybe Windows is magically immune.
>>> 
>>> Unlikely.  More likely is that we need some specific metrics of the
>>> displayed stuff to see the problem (which is therefore very rare).
>> 
>> I agree with this sentiment: it does seem to require special tuning to reveal itself.  I wanted to check to see if you had received my news that I reproduced the line-skip motion bug on a GNU/Linux system.  That would seem to confirm it’s a general issue with the display/motion code dealing with inline images.  Let me know if I can produce anything else to help with this one.  Thanks.
> 
> I've eventually succeeded in reproducing it.  I will get to it when I
> have time; however, with the current tempest on emacs-devel and other
> urgent issues, I don't know when will that be.

Thanks for the update, glad you could reproduce it.  It will be waiting when you have a moment; hope the dust settles soon.