> On May 7, 2025, at 8:00 AM, Eli Zaretskii wrote: > >  >> >> From: JD Smith >> Date: Tue, 6 May 2025 23:30:02 -0400 >> Cc: 67604@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. No worries at all. You juggle many things and it was a good impetus to get a src debugging setup working (I wish realgud worked better with lldb, but command line is ok for now). It’s also a fairly subtle and specific bug, even though I think it underlies many(/all?) small movement oddities I’ve noticed over the years with inline wrapped wide glyphs. >> 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. I appreciate these tips. I took a long look, and my initial assessment was incorrect — the glyph pixel sizes are correct, but the iterator is confused about where the line start is. IT thinks it is at the beginning of the line, but has in fact over-shot, just to the right of the wrapped wide glyph. Here's a snapshot of the problem. There are no images in the buffer any longer — the gray boxes are both simple specified space applied on single SPC chars. The behavior is the same as before. Point jumps from the beginning of the 2nd line on the light gray stretch right to JUMPS HERE. Other forms of incorrect motion are evident, but this is the most dramatic, so I stick with it.