Subject: bug#14627: 24.2; Vertical frame size shrinking

From: Stephen Berman <[email-masked]>
Date: Mon, 09 Sep 2013 14:23:47 +0200

On Mon, 09 Sep 2013 14:00:33 +0200 martin rudalics <[email-masked]> wrote:

>> The only oddity is that when the Info buffer is selected
>> there is an empty space the width of the frame one line high below the
>> minibuffer.
>
> Which disappears when you demaximize the frame, I suppose.

If I demaximize the frame while the Info buffer is selected and the
empty line is displayed, then the latter remains visible.  But it
disappears after switching to the other buffer, and, with the frame
demaximized, when I switch back to the Info buffer again, it now no
longer reappears.  Moreover, if I now maximize the frame again, with the
same window configuration, the empty line still doesn't reappear.  In
fact, it turns out that it only appears if I maximize the frame before
opening Info the first time; if I then kill the Info buffer with the
frame still maximized and then open Info again, the empty line no longer
appears.

>> However, there is still a shrinking problem.  In KDE clicking the
>> frame's (i.e. WM window's) maximize button with mouse-2 instead of
>> mouse-1 maximizes the frame vertically but not horizontally.  When I do
>> this, then split windows (either vertically or horizontally), open an
>> Info buffer in one window and switch between the windows, then the frame
>> still (i.e. even with your patch) shrinks vertically by one line for
>> each switch back to the Info buffer.  If I drag the border of an
>> unmaximized frame to make it vertically fill the desktop and repeat the
>> recipe, no shrinking occurs.  And if I maximize the frame horizontally
>> by clicking the maximize button with mouse-3 and repeat the recipe,
>> there is also no shrinking.
>
> IIUC in his patch Jan fixed only the fully maximized and the fullscreen
> cases.  So what you see is the old behavior for the partially maximized
> case.

That's also what I assumed.

Steve Berman