GNU bug report logs - #70038
29.3.50; Shift up/down in buffer with images on M-x other-window with some fonts

Previous Next

Full log

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

From: martin rudalics <rudalics <at> gmx.at>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: luangruo <at> yahoo.com, rahguzar <at> zohomail.eu, r.diaz <at> uam.es, rdiaz02 <at> gmail.com,
 70038 <at> debbugs.gnu.org
Subject: Re: bug#70038: 29.3.50; Shift up/down in buffer with images on M-x
 other-window with some fonts
Date: Sun, 7 Apr 2024 10:24:29 +0200

> There's one more aspect of this that bothers me: when we resize the
> mini-window, we set the frame's frozen_window_starts flag, but we seem
> to never reset it.
>
> Martin, can you help out here?  I don't see shrink_mini_window being
> called with non-zero DELTA anywhere, including when the mini-window is
> exited and is resized to its normal one-line height.  Instead, this
> resizing is performed by restore_window_configuration, called from
> read_minibuf, but I don't see FRAME_WINDOWS_FROZEN being reset
> anywhere there.  I don't think it's correct for us to leave the
> frame's frozen_window_starts flag set forever once it was raised,

Just for the record: Here I once used a version of shrink_mini_window
that went as

/** Shrink mini-window W to its minimum height.  */
void
shrink_mini_window (struct window *w)
{
  /* Just attempt to shrink it to zero, grow_mini_window makes sure it
     does not get to small.  */
  FRAME_WINDOWS_FROZEN (WINDOW_XFRAME (w)) = false;
  grow_mini_window (w, -WINDOW_PIXEL_HEIGHT (w));
}

where grow_mini_window took care of the rest.  But I don't call
shrink_mini_window any more and so the flag remains stuck here as well.

> so I
> guess we should do something in minibuffer_unwind to reset that flag?

Would that be sufficient?  Don't we freeze also when resizing the echo
area?

martin

Previous Next

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