GNU bug report logs - #79241
31.0.50; `vertical-motion' not respecting goal column when there is an overlay that spans multiple virtual lines

Previous Next

Full log

Message #40 received at 79241 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Sergio Pastor Pérez <sergio.pastorperez <at> gmail.com>
Cc: 79241 <at> debbugs.gnu.org
Subject: Re: bug#79241: [PATCH v2] Fix incorrect handling of overlays in
 `vertical-motion'
Date: Sun, 24 Aug 2025 21:12:25 +0300

> From: Sergio Pastor Pérez <sergio.pastorperez <at> gmail.com>
> Cc: 79241 <at> debbugs.gnu.org
> Date: Sun, 24 Aug 2025 19:58:47 +0200
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> >> +	  if (it.method == GET_FROM_STRING)
> >> +	    reseat_at_previous_visible_line_start(&it);
> >> +
> >>  	  move_it_in_display_line (&it, ZV, first_x + to_x, MOVE_TO_X);
> >>  	  /* If we find ourselves in the middle of an overlay string
> >>  	     which includes a newline after current string position,
> >
> > Is this needed only for overlays?  What about 'display' text
> > properties?  (There are also other cases when it.method could be
> > GET_FROM_STRING.)  If this is only for overlay strings, we need to use
> >
> >   if (it.method == GET_FROM_STRING && !NILP (it.from_overlay))
> >
> > instead.  Please test this at least with 'display' property strings
> > instead of overlay strings, and see if the same problem happens in
> > that case.  Then we will be able to decide how to write the condition
> > in this case.
> 
> So I've tested this behavior with this display property:
> --8<---------------cut here---------------start------------->8---
> (let* ((start (point))
>        (end (1+ (point)))
>        (ov (make-overlay start end)))
>   (overlay-put ov 'display "--->HELLO\nAnother message\nDONE<---"))
> --8<---------------cut here---------------end--------------->8---

No, this is not what I meant.  I meant to test 'display' text
property, not overlay property.

> I've noticed that *without* applying the patch, there is some unexpected
> behavior in the vertical line movement. With the v2 patch applied this
> is partially corrected so it seems some fix is needed for 'display' text
> properties as well.

This is a slightly different situation, so let's leave it alone for
now and focus on the previous use case.  Your patch fixed the case of
an overlay string, let's see whether it is needed with display strings
from 'display' text properties.

Thanks.

Previous Next

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