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 #19 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] WIP: Fix incorrect handling of overlays in
 `vertical-motion'
Date: Wed, 20 Aug 2025 13:45:49 +0300

> From: Sergio Pastor Pérez <sergio.pastorperez <at> gmail.com>
> Cc: Eli Zaretskii <eliz <at> gnu.org>
> Date: Tue, 19 Aug 2025 21:44:55 +0200
> 
> I've debugged the `vertical-motion' procedure and found the troublesome
> code. This patch solves the issue with the goal column, but it has 1
> corner case to that I don't know how to solve.

Thanks for working on this.

> > --- a/src/indent.c
> > +++ b/src/indent.c
> > @@ -2513,15 +2513,16 @@ line (if such column exists on that line, that is).  If the line is
> >  	     and then reposition point at the requested X coordinate;
> >  	     if we don't, the cursor will be placed just after the
> >  	     string, which might not be the requested column.  */
> > -	  if (nlines >= 0 && it.area == TEXT_AREA)
> > +	  if (nlines != 0 && it.area == TEXT_AREA)
> >  	    {
> >  	      while (it.method == GET_FROM_STRING
> > -		     && !it.string_from_display_prop_p
> >  		     && memchr (SSDATA (it.string) + IT_STRING_BYTEPOS (it),
> >  				'\n',
> >  				SBYTES (it.string) - IT_STRING_BYTEPOS (it)))
> >  		{
> > -		  move_it_by_lines (&it, 1);
> > +		  int direction = (nlines > 0) ? 1 : -1;
> > +
> > +		  move_it_by_lines (&it, direction);
> >  		  move_it_in_display_line (&it, ZV, first_x + to_x, MOVE_TO_X);
> >  		}
> 
> I don't know what primitives are available to break this loop once the
> target line has been reached, so what seems to happen is that if there
> are consecutive lines with multi-line overlays, one after the other,
> this while loop keeps going until it reaches the first one of them. This
> is only a problem for the upward motion. Since I did not find a
> solution, I'm writing this mail in case there is someone more familiar
> with the code, that knows how we could detect that the while loop should
> finish in this particular case of consecutive lines with multi-line
> overlays. In all other cases I've encountered, the patch seems to work
> well.

What is the "target line" in this case? how is it defined? and why
going all the way till the first line of a multi-line overlay is not
TRT in this case?

Previous Next

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