bug#55312: 29.0.50; Cannot set vscroll when mini-window is resized

[Po Lu]

It seems that this code in redisplay_window always clears out the
vscroll when the mini-window is taller than a single line of text:

  /* If someone specified a new starting point but did not insist,
     check whether it can be used.  */
  if ((w->optional_new_start || window_frozen_p (w))
      && CHARPOS (startp) >= BEGV
      && CHARPOS (startp) <= ZV)
    {
      ptrdiff_t it_charpos;

      w->optional_new_start = false;
      start_display (&it, w, startp);
      move_it_to (&it, PT, 0, it.last_visible_y, -1,
                  MOVE_TO_POS | MOVE_TO_X | MOVE_TO_Y);
      /* Record IT's position now, since line_bottom_y might change
         that.  */
      it_charpos = IT_CHARPOS (it);
      /* Make sure we set the force_start flag only if the cursor row
         will be fully visible.  Otherwise, the code under force_start
         label below will try to move point back into view, which is
         not what the code which sets optional_new_start wants.  */
      if ((it.current_y == 0 || line_bottom_y (&it) < it.last_visible_y)
          && !w->force_start)
        {
          if (it_charpos == PT)
            w->force_start = true;
          /* IT may overshoot PT if text at PT is invisible.  */
          else if (it_charpos > PT && CHARPOS (startp) <= PT)
            w->force_start = true;

This can easily be reproduced by typing "M-x C-q C-j" and trying to use
`pixel-scroll-precision' with the mouse pointer on top of a window that
is not the `minibuf-scroll-window': the vscroll will not take effect,
since force_start will be set to true, and that resets the vscroll.

I think this "frozen" behavior is required to ensure that the start of
windows do not aimlessly move when the mini-window is being resized, but
it interferes with features that need to set the vscroll.

Any ideas?

Thanks in advance.