Subject: Re: bug#67604: Motion problems with inline images

From: JD Smith <[email-masked]>
Date: Tue, 5 Dec 2023 23:33:42 -0500

> On Dec 5, 2023, at 10:31 PM, Eli Zaretskii <[email-masked]> wrote:
> 
>> From: JD Smith <[email-masked]>
>> Date: Tue, 5 Dec 2023 18:06:41 -0500
>> Cc: [email-masked]
>> 
>>>> 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.