From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#16051: 24.3.50; Emacs hang - resize frame manually Date: Mon, 23 Dec 2013 22:18:12 +0200 Message-ID: <83mwjr724b.fsf@gnu.org> 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> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1387829951 17319 80.91.229.3 (23 Dec 2013 20:19:11 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 23 Dec 2013 20:19:11 +0000 (UTC) Cc: jarekczek@poczta.onet.pl, 16051@debbugs.gnu.org To: martin rudalics Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Dec 23 21:19:16 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 1VvBy6-0006q3-Ue for geb-bug-gnu-emacs@m.gmane.org; Mon, 23 Dec 2013 21:19:15 +0100 Original-Received: from localhost ([::1]:35237 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VvBy6-0004ae-Hl for geb-bug-gnu-emacs@m.gmane.org; Mon, 23 Dec 2013 15:19:14 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:43056) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VvBxz-0004RU-VJ for bug-gnu-emacs@gnu.org; Mon, 23 Dec 2013 15:19:12 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VvBxv-0002cs-BB for bug-gnu-emacs@gnu.org; Mon, 23 Dec 2013 15:19:07 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:50760) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VvBxv-0002cm-7z for bug-gnu-emacs@gnu.org; Mon, 23 Dec 2013 15:19:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1VvBxu-0005SA-BG for bug-gnu-emacs@gnu.org; Mon, 23 Dec 2013 15:19:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 23 Dec 2013 20:19: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.138782993620943 (code B ref 16051); Mon, 23 Dec 2013 20:19:02 +0000 Original-Received: (at 16051) by debbugs.gnu.org; 23 Dec 2013 20:18:56 +0000 Original-Received: from localhost ([127.0.0.1]:36546 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VvBxo-0005Ri-3V for submit@debbugs.gnu.org; Mon, 23 Dec 2013 15:18:56 -0500 Original-Received: from mtaout20.012.net.il ([80.179.55.166]:53397) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VvBxl-0005RX-Gd for 16051@debbugs.gnu.org; Mon, 23 Dec 2013 15:18:55 -0500 Original-Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0MYA00E000447F00@a-mtaout20.012.net.il> for 16051@debbugs.gnu.org; Mon, 23 Dec 2013 22:18:18 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MYA00EFI0EH0O80@a-mtaout20.012.net.il>; Mon, 23 Dec 2013 22:18:18 +0200 (IST) In-reply-to: <52B896D0.8050904@gmx.at> X-012-Sender: halo1@inter.net.il 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:82469 Archived-At: > Date: Mon, 23 Dec 2013 21:02:24 +0100 > From: martin rudalics > CC: jarekczek@poczta.onet.pl, 16051@debbugs.gnu.org > > > 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 | +------> 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. > > delta = nlines - FRAME_TOOL_BAR_LINES (f); > > > > /* Don't resize the tool-bar to more than we have room for. */ > > root_window = FRAME_ROOT_WINDOW (f); > > root_height = WINDOW_TOTAL_LINES (XWINDOW (root_window)); > > if (root_height - delta < 1) > > { > > delta = root_height - 1; > > nlines = FRAME_TOOL_BAR_LINES (f) + delta; > > } > > > > FRAME_TOOL_BAR_LINES (f) = nlines; > > I understand its meaning and also that the subsequent call to > resize_frame_windows is OK. But, as stated above, the toolbar is not > shrunk to one line. 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. > >> IIUC we want to pretend that the frame has the full toolbar (probably as > >> many rows as it has items), a one line root window and, if it's present, > >> a one line minibuffer window. This should be robust enough to avoid a > >> crash. > > > > There's no crash anymore, at least not on Windows. But doing what you > > suggest above means we will need to resize the entire frame, something > > we never did. > > 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. 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.