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: Tue, 24 Dec 2013 19:34:04 +0200 Message-ID: <83a9fq6tmb.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> <83mwjr724b.fsf@gnu.org> <52B95E81.6070208@gmx.at> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1387906512 27805 80.91.229.3 (24 Dec 2013 17:35:12 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 24 Dec 2013 17:35:12 +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 Tue Dec 24 18:35:17 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 1VvVsx-0003lx-5h for geb-bug-gnu-emacs@m.gmane.org; Tue, 24 Dec 2013 18:35:15 +0100 Original-Received: from localhost ([::1]:39902 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VvVsw-0008O9-Q5 for geb-bug-gnu-emacs@m.gmane.org; Tue, 24 Dec 2013 12:35:14 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55546) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VvVsp-0008L9-Gd for bug-gnu-emacs@gnu.org; Tue, 24 Dec 2013 12:35:12 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VvVsk-00055z-Te for bug-gnu-emacs@gnu.org; Tue, 24 Dec 2013 12:35:07 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:53622) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VvVsk-00055v-Pl for bug-gnu-emacs@gnu.org; Tue, 24 Dec 2013 12:35:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1VvVsk-0007GT-Gn for bug-gnu-emacs@gnu.org; Tue, 24 Dec 2013 12:35: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: Tue, 24 Dec 2013 17:35: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.138790645427832 (code B ref 16051); Tue, 24 Dec 2013 17:35:02 +0000 Original-Received: (at 16051) by debbugs.gnu.org; 24 Dec 2013 17:34:14 +0000 Original-Received: from localhost ([127.0.0.1]:39408 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VvVrx-0007Ep-P9 for submit@debbugs.gnu.org; Tue, 24 Dec 2013 12:34:14 -0500 Original-Received: from mtaout22.012.net.il ([80.179.55.172]:52369) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VvVru-0007Ea-QB for 16051@debbugs.gnu.org; Tue, 24 Dec 2013 12:34:12 -0500 Original-Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0MYB00I00NCHQD00@a-mtaout22.012.net.il> for 16051@debbugs.gnu.org; Tue, 24 Dec 2013 19:34:08 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MYB00I98NGVKB50@a-mtaout22.012.net.il>; Tue, 24 Dec 2013 19:34:08 +0200 (IST) In-reply-to: <52B95E81.6070208@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:82535 Archived-At: > Date: Tue, 24 Dec 2013 11:14:25 +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 > > 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. Right. > /* 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. Yes, it is. Not very nice, but if the user wants that, she will get what she asks for. > >> 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. I think we are miscommunicating, because we certainly don't change the frame size; the user does. > > 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. That's too drastic I think. We are perfectly capable of displaying the tool bar truncated to the part that can be rendered. If the user doesn't like that, she can always turn off the tool bar manually. After all, it's the user who caused this.