GNU bug report logs - #14627
24.2; Vertical frame size shrinking

Previous Next

Full log

View this message in rfc822 format

From: Stephen Berman <stephen.berman <at> gmx.net>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 14627 <at> debbugs.gnu.org, Karl Brodowsky <bk1 <at> gmx.net>, Jan Djärv <jan.h.d <at> swipnet.se>, Eli Zaretskii <eliz <at> gnu.org>
Subject: bug#14627: 24.2; Vertical frame size shrinking
Date: Sun, 15 Feb 2015 14:38:12 +0100

On Fri, 13 Feb 2015 19:23:43 +0100 martin rudalics <rudalics <at> gmx.at> wrote:

>> I've now updated and confirm that with the recipe I gave -- frame
>> maximized with side by side windows, one containing an Info buffer --
>> switching between the windows no longer causes the frame to shrink
>> vertically.  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.
>
> Does this still happen with current trunk/master?

No, I don't see this now.

>> 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.
>
> And this?

No, I also see no shrinking problem anymore.

Steve Berman

Previous Next

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