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: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: tracker <at> debbugs.gnu.org
Subject: bug#77217: closed (31.0.50; cursor stuck on long image under
 display-line-numbers-mode and visual-line-mode)
Date: Thu, 03 Apr 2025 07:25:02 +0000

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

Your message dated Thu, 03 Apr 2025 10:23:51 +0300
with message-id <86r029zp14.fsf <at> gnu.org>
and subject line Re: bug#77217: move_it_to moves point to line after to_charpos when to_charpos is an image.
has caused the debbugs.gnu.org bug report #77217,
regarding 31.0.50; cursor stuck on long image under display-line-numbers-mode and visual-line-mode
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs <at> gnu.org.)


-- 
77217: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=77217
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems

[Message part 2 (message/rfc822, inline)]

From: Yifan Zhu <fanzhuyifan <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 31.0.50; cursor stuck on long image under display-line-numbers-mode
 and visual-line-mode
Date: Sun, 23 Mar 2025 11:45:12 -0700

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

--text follows this line--

emacs -Q test.txt (attached)
insert image (long.png, attached) after last word in second line, no space
(set-frame-size (selected-frame) 80 36)
increase size (ctrl+scroll) (see reference.png, attached)
move cursor to bottom and try to move cursor back up
cursor gets stuck at the image


In GNU Emacs 31.0.50 (build 22, x86_64-pc-linux-gnu, GTK+ Version
3.24.49, cairo version 1.18.4)
Repository revision: 9e005e9da06f71441e643f7ecbe309e35f68680a
Repository branch: master
System Description: Arch Linux

Configured using:
'configure --with-pgtk --sysconfdir=/etc --localstatedir=/var
--disable-build-details --with-cairo --with-harfbuzz --with-libsystemd
--with-modules --with-native-compilation=aot --with-tree-sitter
'CFLAGS=-ggdb3 -O0' 'CXXFLAGS=-ggdb3 -O0' LDFLAGS=-ggdb3
--prefix=/home/yifan/packages/emacs-git/build
--exec-prefix=/home/yifan/packages/emacs-git/build'

Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG
LCMS2 LIBOTF LIBSYSTEMD LIBXML2 MODULES NATIVE_COMP NOTIFY INOTIFY
PDUMPER PGTK PNG RSVG SECCOMP SOUND SQLITE3 THREADS TIFF
TOOLKIT_SCROLL_BARS TREE_SITTER WEBP XIM GTK3 ZLIB

Important settings:
value of $LANG: en_US.utf8
value of $XMODIFIERS: @im=fcitx
locale-coding-system: utf-8-unix

Major mode: Text

Minor modes in effect:
text-scale-mode: t
display-line-numbers-mode: t
tooltip-mode: t
global-eldoc-mode: t
show-paren-mode: t
electric-indent-mode: t
mouse-wheel-mode: t
tool-bar-mode: t
menu-bar-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
blink-cursor-mode: t
minibuffer-regexp-mode: t
line-number-mode: t
visual-line-mode: t
indent-tabs-mode: t
transient-mark-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug lisp-mnt message mailcap yank-media puny
dired dired-loaddefs rfc822 mml mml-sec password-cache epa derived epg
rfc6068 epg-config gnus-util mm-decode mm-bodies mm-encode mail-parse
rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045
ietf-drums mm-util mail-prsvr mail-utils face-remap compile
text-property-search comint ansi-osc ansi-color ring comp-run bytecomp
byte-compile comp-common rx time-date subr-x cl-loaddefs cl-lib
display-line-numbers rmc iso-transl tooltip cconv eldoc paren electric
uniquify ediff-hook vc-hooks lisp-float-type elisp-mode mwheel
term/pgtk-win pgtk-win term/common-win touch-screen pgtk-dnd tool-bar
dnd fontset image regexp-opt fringe tabulated-list replace newcomment
text-mode lisp-mode prog-mode register page tab-bar menu-bar rfn-eshadow
isearch easymenu timer select scroll-bar mouse jit-lock font-lock syntax
font-core term/tty-colors frame minibuffer nadvice seq simple cl-generic
indonesian philippine cham georgian utf-8-lang misc-lang vietnamese
tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek
romanian slovak czech european ethiopic indian cyrillic chinese
composite emoji-zwj charscript charprop case-table epa-hook
jka-cmpr-hook help abbrev obarray oclosure cl-preloaded button loaddefs
theme-loaddefs faces cus-face macroexp files window text-properties
overlay sha1 md5 base64 format env code-pages mule custom widget keymap
hashtable-print-readable backquote threads dbusbind inotify
dynamic-setting system-font-setting font-render-setting cairo gtk pgtk
lcms2 multi-tty move-toolbar make-network-process tty-child-frames
native-compile emacs)

Memory information:
((conses 16 67339 20133) (symbols 48 6859 0) (strings 32 17412 2459)
(string-bytes 1 703591) (vectors 16 10908)
(vector-slots 8 151951 9248) (floats 8 28 20) (intervals 56 284 0)
(buffers 992 14))

[reference.png (image/png, attachment)]

[test.txt (text/plain, attachment)]

[long.png (image/png, attachment)]

[Message part 7 (message/rfc822, inline)]

From: Eli Zaretskii <eliz <at> gnu.org>
To: Yifan Zhu <fanzhuyifan <at> gmail.com>
Cc: 77217-done <at> debbugs.gnu.org
Subject: Re: bug#77217: move_it_to moves point to line after to_charpos when
 to_charpos is an image.
Date: Thu, 03 Apr 2025 10:23:51 +0300

> Date: Wed, 26 Mar 2025 10:57:24 -0700
> Cc: 77217 <at> debbugs.gnu.org
> From: Yifan Zhu <fanzhuyifan <at> gmail.com>
> 
> 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.

No further comments, so I'm now closing this bug.

Previous Next

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