bug#52302: 28.0.50; [PATCH] Overlay strings should not increment vpos

[Eli Zaretskii <eliz@gnu.org>]

> From: dick <dick.r.chiang@gmail.com>
> Date: Mon, 06 Dec 2021 14:47:45 -0500
> 
> A more dangerous change like the below would break the cycle of fixes
> that minimize impact while maximizing obfuscation.
> 
> >From 5f734c1d50953836dda444b8371642c6f20d4065 Mon Sep 17 00:00:00 2001
> From: dickmao <dick.r.chiang@gmail.com>
> Date: Mon, 6 Dec 2021 14:30:17 -0500
> Subject: [PATCH] A small change with disastrous potential
> 
> * src/xdisp.c (move_it_in_display_line_to): How this function has
> managed to get by without a notion of visibility is a real mystery.
> ---
>  src/xdisp.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/src/xdisp.c b/src/xdisp.c
> index 0ff6286af74..1522c6b3193 100644
> --- a/src/xdisp.c
> +++ b/src/xdisp.c
> @@ -9561,7 +9561,7 @@ #define IT_RESET_X_ASCENT_DESCENT(IT)			\
>  
>        PRODUCE_GLYPHS (it);
>  
> -      if (it->area != TEXT_AREA)
> +      if (it->area != TEXT_AREA || it->method == GET_FROM_STRING)
>  	{
>  	  prev_method = it->method;
>  	  if (it->method == GET_FROM_BUFFER)

I don't understand this change.  Glyphs delivered from display and
overlay strings are subject to wrapping and truncation exactly like
glyphs delivered from buffer text.  Only glyphs that are written into
the display margins are silently truncated.  So I don't think your
additional condition is correct.  For example, what happens if there's
a display or overlay string that is very long, so that it overflows
the window width?  This additional condition will cause the code
behave as if the window had infinite width, for the whole time it
traverses the string.