GNU bug report logs - #77217
31.0.50; cursor stuck on long image under display-line-numbers-mode and visual-line-mode

Previous Next

Full log

View this message in rfc822 format

From: Yifan Zhu <fanzhuyifan <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 77217 <at> debbugs.gnu.org
Subject: bug#77217: move_it_to moves point to line after to_charpos when to_charpos is an image.
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: 77217 <at> debbugs.gnu.org
>> From: Yifan Zhu <fanzhuyifan <at> gmail.com>
>>
>> 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!

Previous Next

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