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 21:31:26 +0200 Message-ID: <83ppon74a9.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> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1387827131 17726 80.91.229.3 (23 Dec 2013 19:32:11 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 23 Dec 2013 19:32: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 20:32: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 1VvBEd-0003IY-Gb for geb-bug-gnu-emacs@m.gmane.org; Mon, 23 Dec 2013 20:32:15 +0100 Original-Received: from localhost ([::1]:35099 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VvBEc-0006v0-TO for geb-bug-gnu-emacs@m.gmane.org; Mon, 23 Dec 2013 14:32:14 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:59915) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VvBEU-0006tj-W4 for bug-gnu-emacs@gnu.org; Mon, 23 Dec 2013 14:32:11 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VvBEQ-0004qc-BH for bug-gnu-emacs@gnu.org; Mon, 23 Dec 2013 14:32:06 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:50674) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VvBEQ-0004pi-4W for bug-gnu-emacs@gnu.org; Mon, 23 Dec 2013 14:32:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1VvBEP-0003xJ-IY for bug-gnu-emacs@gnu.org; Mon, 23 Dec 2013 14:32:01 -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 19:32:01 +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.138782711215193 (code B ref 16051); Mon, 23 Dec 2013 19:32:01 +0000 Original-Received: (at 16051) by debbugs.gnu.org; 23 Dec 2013 19:31:52 +0000 Original-Received: from localhost ([127.0.0.1]:36460 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VvBEF-0003wx-Me for submit@debbugs.gnu.org; Mon, 23 Dec 2013 14:31:52 -0500 Original-Received: from mtaout23.012.net.il ([80.179.55.175]:56322) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VvBEC-0003wd-Sq for 16051@debbugs.gnu.org; Mon, 23 Dec 2013 14:31:50 -0500 Original-Received: from conversion-daemon.a-mtaout23.012.net.il by a-mtaout23.012.net.il (HyperSendmail v2007.08) id <0MY900800Y7CCK00@a-mtaout23.012.net.il> for 16051@debbugs.gnu.org; Mon, 23 Dec 2013 21:31:32 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout23.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MY9008E6Y8K9D80@a-mtaout23.012.net.il>; Mon, 23 Dec 2013 21:31:32 +0200 (IST) In-reply-to: <52B88491.1000903@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:82464 Archived-At: > Date: Mon, 23 Dec 2013 19:44:33 +0100 > From: martin rudalics > CC: jarekczek@poczta.onet.pl, 16051@debbugs.gnu.org > > - it.last_visible_x = FRAME_TOTAL_COLS (f) * FRAME_COLUMN_WIDTH (f); > + it.last_visible_x = WINDOW_PIXEL_WIDTH (w); > > Wonderful. The effect of this was visible in the Lucid/Motif builds but > since I hadn't seen it in the Windows build I didn't expect to find the > cause in the toolkit independent part of the code. But is this related > to the current bug? Yes, definitely. redisplay_tool_bar was using WINDOW_PIXEL_WIDTH, while tool_bar_height was using FRAME_TOTAL_COLS (f) * FRAME_COLUMN_WIDTH (f) so these two were inconsistent with each other, and when the former claimed (correctly) that there's not enough space to draw the tool bar in one row, tool_bar_height was (incorrectly) returning 1 as the required number of rows. And then you set the fonts_changed flag, which starts the infloop... > As an aside, I have never been able to understand the purpose of the > tool-bar-lines parameter. IIUC we are only supposed to read its value > from Lisp but never to set it to anything but zero or one. Am I right? 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. Maybe you meant the n_tool_bar_rows member of 'struct frame' instead? But that, too, is not always 1, it can be greater. Confused... > > If there is some reasoning behind this "always do that" logic, please > > describe it. Otherwise, I propose the patch below, which cures the > > problem altogether for me; if you agree, I will install it. > > I certainly agree :-) OK, installed as trunk revision 115720. > > As an aside, I stared for a long time at this part of > > w32fns.c:x_set_tool_bar_lines (which is part of the issue, because it > > is called by modify-frame-parameters, when the tool-bar-lines > > parameter is changed), and I still don't get why it does what it does: > > root_height = WINDOW_PIXEL_HEIGHT (XWINDOW (FRAME_ROOT_WINDOW (f))); > > if (root_height - delta < unit) > > How would you know - it probably doesn't do anything reasonable. When > we enter this part we see only the upper part of the first row of the > toolbar, the rest of the toolbar, root and minibuffer window being > clipped by the window manager. Actually, we enter there any time a change is requested for the frame's tool-bar-lines parameter, and the change is so large it will leave no space for the rest of the root window. > > { > > delta = root_height - unit; > > nlines = (root_height / unit) + min (1, (root_height % unit)); > > } > > > > First, delta is recomputed, but the result is never used. More > > importantly, you assign to nlines a value that is the size of the root > > window _plus_ one line? Did you mean minus instead? > > Probably. If you have any good idea what to do here, please do it. 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: 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; Translation of this to pixels is straightforward, but it looks like you wanted to do something different 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. > 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? > > Finally, the corresponding xfns.c implementation still works in lines, > > not in pixels, as w32fns.c did before your pixelwise changes. Is this > > disparity on purpose or an oversight? > > When I installed my changes I tested this only with the Windows and the > Gtk builds. It's only now that I encountered problems with the Lucid > and Motif builds. I'm working on this currently. OK, thanks.