From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.bugs Subject: bug#16051: 24.3.50; Emacs hang - resize frame manually Date: Tue, 24 Dec 2013 11:14:25 +0100 Message-ID: <52B95E81.6070208@gmx.at> References: <3eea48d4-9267-45fa-84c8-3eb9c9290558@default> <52B59B44.9060307@poczta.onet.pl> <83a9fu9r1j.fsf@gnu.org> <52B5B7EA.2080809@poczta.onet.pl> <837gay9nx2.fsf@gnu.org> <52B5CC35.10404@gmx.at> <83zjnr7bea.fsf@gnu.org> <52B88491.1000903@gmx.at> <83ppon74a9.fsf@gnu.org> <52B896D0.8050904@gmx.at> <83mwjr724b.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1387880117 11946 80.91.229.3 (24 Dec 2013 10:15:17 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 24 Dec 2013 10:15:17 +0000 (UTC) Cc: jarekczek@poczta.onet.pl, 16051@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Dec 24 11:15:22 2013 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1VvP1F-00031x-B5 for geb-bug-gnu-emacs@m.gmane.org; Tue, 24 Dec 2013 11:15:21 +0100 Original-Received: from localhost ([::1]:37303 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VvP1E-0006FK-Bh for geb-bug-gnu-emacs@m.gmane.org; Tue, 24 Dec 2013 05:15:20 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:48365) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VvP14-0006FC-OM for bug-gnu-emacs@gnu.org; Tue, 24 Dec 2013 05:15:18 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VvP0x-0006ot-DI for bug-gnu-emacs@gnu.org; Tue, 24 Dec 2013 05:15:10 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:52012) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VvP0x-0006o5-9N for bug-gnu-emacs@gnu.org; Tue, 24 Dec 2013 05:15:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1VvP0w-0007Ck-Mf for bug-gnu-emacs@gnu.org; Tue, 24 Dec 2013 05:15:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: martin rudalics Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 24 Dec 2013 10:15:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 16051 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 16051-submit@debbugs.gnu.org id=B16051.138788007727628 (code B ref 16051); Tue, 24 Dec 2013 10:15:02 +0000 Original-Received: (at 16051) by debbugs.gnu.org; 24 Dec 2013 10:14:37 +0000 Original-Received: from localhost ([127.0.0.1]:37797 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VvP0W-0007BX-KY for submit@debbugs.gnu.org; Tue, 24 Dec 2013 05:14:37 -0500 Original-Received: from mout.gmx.net ([212.227.15.18]:58312) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VvP0U-0007BN-07 for 16051@debbugs.gnu.org; Tue, 24 Dec 2013 05:14:35 -0500 Original-Received: from [62.47.39.236] ([62.47.39.236]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0MK3bN-1VwDxF31PB-001O1T for <16051@debbugs.gnu.org>; Tue, 24 Dec 2013 11:14:32 +0100 In-Reply-To: <83mwjr724b.fsf@gnu.org> X-Provags-ID: V03:K0:Zg3u87vhrcoz6g76AMTe3kBgEWXWuuZZRxEeEN2UKG1TTOfY7Xo O+2GJxHdsYfekKIZTn6QF3SYKhYIU8nwIkH5aULUxxt+I7eIhTkBMd71TCMUjQyQlmld6gs 4hDSRnmwRfhFKSjKTZWba3kefevIDzpqnr+v+i7oj0TNdWaMlJYWvDr9Sg43oJcABaCgLA3 vaZijwcN5R/fcmPAWQdHw== X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:82508 Archived-At: >> > If you are right, then I'm confused: the call to >> > Fmodify_frame_parameters that changes the tool-bar-lines parameter >> > leads to a call to x_set_tool_bar_lines, which in turn resizes the >> > tool-bar window. And the value is certainly not always 1, I've seen >> > it as large as 7. >> >> This must be the display code which takes the deviation via the frame >> parameter to communicate the new size to resize_frame_windows. Not very >> clean IMHO. > > No, that's not what happens. What happens is this call sequence: > > Fmodify_frame_parameters Who calls Fmodify_frame_parameters here? It's redisplay_tool_bar in if (new_height != WINDOW_PIXEL_HEIGHT (w)) ... Fmodify_frame_parameters (frame, list1 (Fcons (Qtool_bar_lines, make_number (new_lines)))); discovering that the present line doesn't suffice. > | > +------> x_set_frame_parameters > | > +-------> x_set_tool_bar_lines > > (The last call is via the FRAME_RIF (f)->frame_parm_handlers[] array.) > >> > Well, the old code simply left at least one screen line to the window, >> > and if the tool bar asked for more than that, its request was not >> > honored: >> >> This is not what I see with 24.3: With emacs -Q make the frame very >> narrow and shrink its height. Here I see 3 tool-bar lines but no root >> or minibuffer window. > > I'm talking about what the code did, not about the effect. FWIW, > Emacs 24.3 just hits an assertion when I try that: > > xdisp.c:1053: Emacs fatal error: assertion failed: height >= 0 > > I guess your Emacs 24.3 is built without --enable-checking. Probably. Not entirely relieving to see that the problem is not new. > The code above does not attempt to shrink the toolbar to one line, it > limits the DELTA, i.e. the additional lines the toolbar will get, to > the height of the frame's root window minus one line. IOW, it shrinks > the rest of the root window to one line. And this is completely wrong at this place. I already marked the problem when I applied my changes but forgot about it. It's here: /* Max tool-bar height. Basically, this is what makes all other windows disappear when the frame gets too small. Rethink this! */ #define MAX_FRAME_TOOL_BAR_HEIGHT(f) \ ((FRAME_LINE_HEIGHT (f) * FRAME_LINES (f))) This means that the toolbar is allowed to grasp the whole frame, killing everything else. >> No. I meant to keep the frame size fixed at some minimum value and let >> the window manager do the clipping - just as it does now. > > The frame size should remain as it was -- as the user determined by > dragging. But this means that we currently do change the frame size. > We should not change it. The question is what value should > we limit the tool bar to, given those constraints, and how much space > should we leave to the rest of the root window of the frame. What we do when there's no toolbar, I presume. That is, if there's not enough space, then kill the toolbar. martin