Subject: bug#77217: move_it_to moves point to line after to_charpos when to_charpos is an image.

From: Yifan Zhu <[email-masked]>
Date: Wed, 26 Mar 2025 10:57:24 -0700

On 3/26/25 10:16 AM, Eli Zaretskii wrote:
>> Date: Wed, 26 Mar 2025 09:39:18 -0700
>> Cc: [email-masked]
>> From: Yifan Zhu <[email-masked]>
>>
>> An updated patch resolves the issue (also attached):
>>
>> diff --git a/src/xdisp.c b/src/xdisp.c
>> index 4e8bb7d9b97..c6b87b08ae9 100644
>> --- a/src/xdisp.c
>> +++ b/src/xdisp.c
>> @@ -31956,12 +31956,14 @@ produce_image_glyph (struct it *it)
>>        word-wrap, unless the image starts at column zero, because
>>        wrapping correctly needs the real pixel width of the image.  */
>>     if ((it->line_wrap != WORD_WRAP
>> -       || it->hpos == 0
>> +       || it->hpos == (it->lnum_width ? it->lnum_width + 2 : 0)
>>          /* Always crop images larger than the window-width, minus 1 space.  */
>> -       || it->pixel_width > it->last_visible_x - FRAME_COLUMN_WIDTH (it->f))
>> +       || it->pixel_width > it->last_visible_x - FRAME_COLUMN_WIDTH (it->f)
>> +                                - it->lnum_pixel_width)
>>         && (crop = it->pixel_width - (it->last_visible_x - it->current_x),
>> -         crop > 0)
>> -      && (it->hpos == 0 || it->pixel_width > it->last_visible_x / 4))
>> +          crop > 0)
>> +      && (it->hpos == (it->lnum_width ? it->lnum_width + 2 : 0)
>> +          || it->pixel_width > it->last_visible_x / 4))
>>       {
>>         it->pixel_width -= crop;
>>         slice.width -= crop;
> Thanks, this is almost the same as my original patch, with the
> addition of one more fix.  So I merged your addition with my original
> changes and installed that on the master branch.
Thanks! I had a small nit about the redundant "0 +"s in your original 
patch. But it doesn't really matter.
>
>> However, I think that images wider than the line should always start on a new line, instead of being almost
>> clipped on the current line. E.g., see bad_clipping.png. Do you think I should file a separate bug report for
>> this?
> You could file a bug, but I'm not sure this will or even should be
> changed.  I certainly don't plan working on such a change.  Emacs
> behaved like it does now since v21.1: wide images are cropped at the
> right edge of the window.  That's because, unlike with text, there's
> no way of continuing a wide image on the next screen line.  Starting
> such images on the next line will not solve the problem completely,
> because an image could be wider than the window to begin with; the
> clear disadvantage is that you waste one more screen line.  So we use
> a heuristic: if the image's width is more than 1/4th of the window, we
> always crop it.  I don't think there are better alternatives.
>
> If this is somehow problematic in the specific case where you bumped
> into this, my suggestion is to break wide images into several narrower
> ones, or maybe use the 'slice' feature of the Emacs display of images.

Makes sense -- it was just a small issue I found when testing out the 
change, and not really something that annoys me in my workflow.

Thanks again!