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

Previous Next

Full log

View this message in rfc822 format

From: Jan Djärv <jan.h.d <at> swipnet.se>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: martin rudalics <rudalics <at> gmx.at>, bk1 <at> gmx.net, stephen.berman <at> gmx.net, 14627 <at> debbugs.gnu.org
Subject: bug#14627: 24.2; Vertical frame size shrinking
Date: Fri, 23 Aug 2013 18:22:16 +0200

Hello.

23 aug 2013 kl. 13:10 skrev Eli Zaretskii <eliz <at> gnu.org>:

>> Date: Fri, 23 Aug 2013 12:46:01 +0200
>> From: martin rudalics <rudalics <at> gmx.at>
>> CC: stephen.berman <at> gmx.net, 14627 <at> debbugs.gnu.org, bk1 <at> gmx.net
>> 
>>>> The OP uses cyrillic and Stephen invokes Info, could these give a
>>>> clue?
>>> 
>>> I don't think so, certainly not with Info.
>> 
>> Info has a special toolbar.
> 
> Right, but we already talked about that: only image sizes can change
> the toolbar's size.

In 99 cases out of 100 these cases are due to either the inherent race in wm_size_hints or bugs in the window manager.  In this case it is probably the latter.

I suspect the tool bar changes for the OP.  That makes Emacs send new wm_size_hints to the window manager, telling it what the base- and increment sizes are.  If the tool bar changes, the base size changes (the size not counted against resize increments, i.e. font size).  Normally a window manager shall then make sure Emacs frame has the appropriate size, i.e.

    height = base_y + inc_y * n

where n is an integer.

But in this case the frame is maximized, so the window manager should do nothing, like all other window managers.

A possible workaround is not to update size hints when Emacs is maximized or fullscreen.

	Jan D.

Previous Next

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