Subject: bug#79241: [PATCH v2] Fix incorrect handling of overlays in `vertical-motion'

From: Eli Zaretskii <[email-masked]>
Date: Sun, 24 Aug 2025 14:27:32 +0300

> Cc: Sergio Pastor Pérez <[email-masked]>
> From: Sergio Pastor Pérez <[email-masked]>
> Date: Sun, 24 Aug 2025 13:13:01 +0200
> 
> * src/indent.c (vertical-motion): If point is inside an overlay, reset
> it to the beginning of line before trying to reach goal column. This
> prevents point from being stuck at the beginning of overlay strings
> during upward motions.
> ---
>  src/indent.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/src/indent.c b/src/indent.c
> index b4f3c349dc5..01865c1494f 100644
> --- a/src/indent.c
> +++ b/src/indent.c
> @@ -2506,6 +2506,9 @@ line (if such column exists on that line, that is).  If the line is
>  	 an addition to the hscroll amount.  */
>        if (!NILP (lcols))
>  	{
> +	  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.

Thanks.