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

Previous Next

Full log

Message #77 received at 67604 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: JD Smith <jdtsmith <at> gmail.com>
Cc: 67604 <at> debbugs.gnu.org
Subject: Re: bug#67604: Motion problems with inline images
Date: Wed, 07 May 2025 15:00:35 +0300

> From: JD Smith <jdtsmith <at> gmail.com>
> Date: Tue, 6 May 2025 23:30:02 -0400
> Cc: 67604 <at> debbugs.gnu.org
> 
> > 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.
> 
> This bug remains present in Emacs v30.

Sorry, I couldn't find the time to look at this.

> What I'm looking for is a reason why a wide glyph (only) at the very start of a wrapped visual display line would have its pixel width incorrectly stored, as if it were just a regular width character.  
> 
> I tried to get a sense of where this IT pixel_width is getting set, but it's referenced all over xdisp.c, and I have only a rudimentary understanding of the iterator structure (and its glyph rows, etc.).
> 
> If you have any hunches where this mistaken it->pixel_width might be sneaking in for wrapped wide glyphs, I'd be very happy to investigate further using my debug setup here.

it->pixel_width comes from the call to PRODUCE_GLYPHS (which is a
macro that calls gui_produce_glyphs).  For characters,
gui_produce_glyphs does the job itself, under this condition:

  if (it->what == IT_CHARACTER)

For images, it calls produce_image_glyph.

I hope this is the information you were looking for.  If not, please
ask more specific questions.

Thanks.

Previous Next

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