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: Mon, 23 Dec 2013 21:02:24 +0100 Message-ID: <52B896D0.8050904@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> 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 1387829001 6628 80.91.229.3 (23 Dec 2013 20:03:21 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 23 Dec 2013 20:03:21 +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 Mon Dec 23 21:03:24 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 1VvBim-0002Lo-JE for geb-bug-gnu-emacs@m.gmane.org; Mon, 23 Dec 2013 21:03:24 +0100 Original-Received: from localhost ([::1]:35171 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VvBim-0005tN-70 for geb-bug-gnu-emacs@m.gmane.org; Mon, 23 Dec 2013 15:03:24 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:38463) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VvBia-0005h2-5f for bug-gnu-emacs@gnu.org; Mon, 23 Dec 2013 15:03:19 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VvBiS-0005gB-Rh for bug-gnu-emacs@gnu.org; Mon, 23 Dec 2013 15:03:12 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:50729) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VvBiS-0005g4-PF for bug-gnu-emacs@gnu.org; Mon, 23 Dec 2013 15:03:04 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1VvBiR-0004xo-QV for bug-gnu-emacs@gnu.org; Mon, 23 Dec 2013 15:03:04 -0500 X-Loop: help-debbugs@gnu.org Resent-From: martin rudalics Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 23 Dec 2013 20:03: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.138782895619032 (code B ref 16051); Mon, 23 Dec 2013 20:03:02 +0000 Original-Received: (at 16051) by debbugs.gnu.org; 23 Dec 2013 20:02:36 +0000 Original-Received: from localhost ([127.0.0.1]:36514 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VvBhz-0004wt-En for submit@debbugs.gnu.org; Mon, 23 Dec 2013 15:02:35 -0500 Original-Received: from mout.gmx.net ([212.227.17.22]:56975) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VvBhw-0004wh-Ei for 16051@debbugs.gnu.org; Mon, 23 Dec 2013 15:02:33 -0500 Original-Received: from [62.47.63.246] ([62.47.63.246]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0LlVZv-1VNlth46lj-00bI7y for <16051@debbugs.gnu.org>; Mon, 23 Dec 2013 21:02:31 +0100 In-Reply-To: <83ppon74a9.fsf@gnu.org> X-Provags-ID: V03:K0:o+CwRbhUZVSFeEy6zs6cHEgq/r0Q38UyXEz8e1HD/3PPPe7Autf XPQ2JKIwZn6GIC6lkIjee7OnW29Xz55h33AN2js75Sm+vFNd5J23X+jVn4/CxYaSvkvy2tq PPocutCe6MatqefW1fJfttDjEwd0Et74n2Z2j2a7xgZ0XY8Ds57XQLhsZ52OH1ntw7xUKB6 GL0aD7wbVGUDEPmbsRRiA== 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:82467 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. > 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. > 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 change does not get propagated back to the display engine to display less lines. Or am I missing something? > Translation of this to pixels is straightforward, but it looks like > you wanted to do something different here? I can do that translation but would rather like to understand first what really goes on here. >> 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. >> But the underlying problem, namely that shrinking the width of the frame >> may mean that we'd have to enlarge its height, remains. Currently, our >> internal toolbar gets nominally larger than the containing frame. > > It gets larger and is displayed only partially. I think this is > reasonable under these circumstances: if the user does dumb things, > which shouldn't we let her suffer? The problem is not that it gets larger. The problem is that it gets larger than the containing frame. OTOH if Emacs thinks that it has only one line that might be good enough for us. martin