GNU bug report logs - #67604
Motion problems with inline images

Previous Next

Full log

View this message in rfc822 format

From: JD Smith <jdtsmith <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 67604 <at> debbugs.gnu.org
Subject: bug#67604: Motion problems with inline images
Date: Wed, 6 Dec 2023 13:29:54 -0500

[Message part 1 (text/plain, inline)]

> On Dec 6, 2023, at 7:25 AM, Eli Zaretskii <eliz <at> gnu.org> wrote:
> 
>> From: JD Smith <jdtsmith <at> gmail.com>
>> Date: Tue, 5 Dec 2023 23:33:42 -0500
>> Cc: 67604 <at> 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.

[Message part 2 (text/html, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.