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#4543: window-full-height-p Date: Sat, 26 Sep 2009 23:17:16 +0300 Message-ID: <83k4zlsboz.fsf@gnu.org> References: <4ABB19F5.50908@gmx.at> <4ABC73DB.1060308@gmx.at> <83vdj7tlup.fsf@gnu.org> <4ABCBEC7.70901@gmx.at> <4ABDE2C5.2070808@gmx.at> <83vdj6rllk.fsf@gnu.org> <4ABE1A25.7050909@gmx.at> <83pr9dsmbd.fsf@gnu.org> <4ABE6510.90508@gmx.at> Reply-To: Eli Zaretskii , 4543@emacsbugs.donarmstrong.com NNTP-Posting-Host: lo.gmane.org X-Trace: ger.gmane.org 1253996875 1664 80.91.229.12 (26 Sep 2009 20:27:55 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 26 Sep 2009 20:27:55 +0000 (UTC) Cc: 4543@emacsbugs.donarmstrong.com, monnier@IRO.UMontreal.CA To: martin rudalics Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Sep 26 22:27:48 2009 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1Mrdru-0007iM-MR for geb-bug-gnu-emacs@m.gmane.org; Sat, 26 Sep 2009 22:27:47 +0200 Original-Received: from localhost ([127.0.0.1]:35884 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Mrdrt-0003pA-Uo for geb-bug-gnu-emacs@m.gmane.org; Sat, 26 Sep 2009 16:27:45 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MrdrN-0003Kr-PS for bug-gnu-emacs@gnu.org; Sat, 26 Sep 2009 16:27:13 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MrdrK-0003FV-0E for bug-gnu-emacs@gnu.org; Sat, 26 Sep 2009 16:27:13 -0400 Original-Received: from [199.232.76.173] (port=42035 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MrdrJ-0003FL-LR for bug-gnu-emacs@gnu.org; Sat, 26 Sep 2009 16:27:09 -0400 Original-Received: from rzlab.ucr.edu ([138.23.92.77]:47436) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MrdrJ-0008Cj-5k for bug-gnu-emacs@gnu.org; Sat, 26 Sep 2009 16:27:09 -0400 Original-Received: from rzlab.ucr.edu (rzlab.ucr.edu [127.0.0.1]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n8QKR5Hl013118; Sat, 26 Sep 2009 13:27:06 -0700 Original-Received: (from debbugs@localhost) by rzlab.ucr.edu (8.14.3/8.14.3/Submit) id n8QKK4mp011886; Sat, 26 Sep 2009 13:20:04 -0700 Resent-Date: Sat, 26 Sep 2009 13:20:04 -0700 X-Loop: owner@emacsbugs.donarmstrong.com Resent-From: Eli Zaretskii Resent-To: bug-submit-list@donarmstrong.com Resent-CC: Emacs Bugs 2Resent-Date: Sat, 26 Sep 2009 20:20:04 +0000 Resent-Message-ID: Resent-Sender: owner@emacsbugs.donarmstrong.com X-Emacs-PR-Message: followup 4543 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Original-Received: via spool by 4543-submit@emacsbugs.donarmstrong.com id=B4543.125399612211400 (code B ref 4543); Sat, 26 Sep 2009 20:20:04 +0000 Original-Received: (at 4543) by emacsbugs.donarmstrong.com; 26 Sep 2009 20:15:22 +0000 X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. Original-Received: from mtaout7.012.net.il (mtaout7.012.net.il [84.95.2.19]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n8QKFJ5I011313 for <4543@emacsbugs.donarmstrong.com>; Sat, 26 Sep 2009 13:15:21 -0700 Original-Received: from conversion-daemon.i-mtaout7.012.net.il by i-mtaout7.012.net.il (HyperSendmail v2007.08) id <0KQL00600H6EEX00@i-mtaout7.012.net.il> for 4543@emacsbugs.donarmstrong.com; Sat, 26 Sep 2009 23:15:13 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([77.126.56.156]) by i-mtaout7.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0KQL00KHQHLDHQ70@i-mtaout7.012.net.il>; Sat, 26 Sep 2009 23:15:13 +0300 (IDT) In-reply-to: <4ABE6510.90508@gmx.at> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) Resent-Date: Sat, 26 Sep 2009 16:27:13 -0400 X-BeenThere: bug-gnu-emacs@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:31539 Archived-At: > Date: Sat, 26 Sep 2009 21:01:36 +0200 > From: martin rudalics > CC: 4543@emacsbugs.donarmstrong.com, monnier@IRO.UMontreal.CA > > >> > Why doesn't it make sense? The computed value of new_frame_total_cols > >> > is used to enlarge only the frame's root window: > >> > > >> > if (new_frame_total_cols != FRAME_TOTAL_COLS (f)) > >> > { > >> > set_window_width (FRAME_ROOT_WINDOW (f), new_frame_total_cols, 2); > >> > > >> > And for the root window, FRAME_TOTAL_COLS is correct, I think. The > >> > window configuration, however complex, does not affect the root > >> > window, does it? > >> > >> With Emacs -Q I can evaluate > >> > >> (set-window-scroll-bars nil 0 nil) > >> > >> to remove the scroll bar from the *scratch* window keeping the window > >> size unaltered. When I now evaluate > >> > >> (scroll-bar-mode -1) > >> > >> the width of the frame shrinks and with it the number of columns used > >> for text in the *scratch* window. This doesn't make sense. > > > > Agreed. But I must be missing something because I don't see how this > > behavior is related to the code you quoted above. > > Indeed. The above quotation should have started with > > >> The problem I see is that the value for new_frame_total_cols > >> calculated by change_frame_size_1 as > >> > >> /* Compute width of windows in F. > >> This is the width of the frame without vertical scroll bars. */ > >> new_frame_total_cols = FRAME_TOTAL_COLS_ARG (f, newwidth); > >> > >> /* Round up to the smallest acceptable size. */ > >> check_frame_size (f, &newheight, &newwidth); > >> > >> doesn't make sense for more complex window configurations. > > in order to make clear that the assignment to new_frame_total_cols is > reponsible for the behavior I sketched. We are looping: the more complex window configurations are irrelevant for the root window, I think. > Or the fact that setting `scroll-bar-mode' may trigger > frame-resizing in the first place. What I'm missing is how the code fragments you show are related to the problematic behavior when `scroll-bar-mode' is toggled.