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

Previous Next

Package: emacs;

Reported by: JD Smith <jdtsmith <at> gmail.com>

Date: Sun, 3 Dec 2023 16:56:01 UTC

Severity: normal

Done: Eli Zaretskii <eliz <at> gnu.org>

Full log


Message #98 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: Tue, 27 May 2025 16:23:30 +0300
> From: JD Smith <jdtsmith <at> gmail.com>
> Date: Sat, 17 May 2025 23:13:45 -0400
> Cc: 67604 <at> debbugs.gnu.org
> 
> I have some progress to report.  To keep things simple, I compared two cases, both moving vertically down by one line, starting with point on the just-wrapped green image:
> 
> 1. The "fine-tuned" case, which skips a line.
> 2. A "nearby" case with the same window width that doesn't exhibit the bug (no skip).

Thanks, and sorry for my long delays.  These issues need some time and
a quiet environment, and I don't easily get both together...

> In terms of the special case path for "last glyph just fits":  this is appropriate for (non-word) window wrapping, but not, I believe word-wrapping.  Why? I noticed that wrapped words carry _all_ their trailing whitespace with them when they wrap (presumably to keep WS from wrapping to the start of a display line).  In other words, why care if the green image itself can "barely fit" on a line, when in fact, it will _already have wrapped_ at a larger window width, due to the trailing whitespace (of which there must be at least one).

That condition, i.e.

		  if (/* IT->hpos == 0 means the very first glyph
			 doesn't fit on the line, e.g. a wide
			 image.  */
		      it->hpos == 0  
		      || (new_x == it->last_visible_x  //**!!! FINE-TUNING
			  && FRAME_WINDOW_P (it->f)))

is because GUI windows can show the cursor on the fringe.  So even if
a glyph "barely fits", we can show the cursor after it, and don't need
an extra column of the window's text-area for that purpose.  See
overflow-newline-into-fringe.

Given what you say, it might be TRT to not go there under word-wrap
when the next character can wrap, but please verify that:

 . it->current was already moved to the character after the image,
   because AFAIR char_can_wrap_after looks at the character at
   it->current
 . when this problem happens with the image right next to a newline
   that ends a line, we can still show the cursor on the fringe when
   you move point to the buffer position after the image, both with
   and without word-wrap

If the patch passes these two tests, feel free to install on the
master branch.

> That was a _lot_ of hunting!

It usually is, with tricky display engine issues such as this one.

Thanks!




This bug report was last modified 10 days ago.

Previous Next


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