From rgm@gnu.org Wed Sep 23 20:44:33 2009 Received: (at submit) by emacsbugs.donarmstrong.com; 24 Sep 2009 03:44:33 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-4.5 required=4.0 tests=AWL,ONEWORD,X_DEBBUGS_NO_ACK autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from lists.gnu.org (lists.gnu.org [199.232.76.165]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n8O3iV8W024039 for ; Wed, 23 Sep 2009 20:44:33 -0700 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MqfFv-0002Hm-Fv for bug-gnu-emacs@gnu.org; Wed, 23 Sep 2009 23:44:31 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MqfFp-0002El-GM for bug-gnu-emacs@gnu.org; Wed, 23 Sep 2009 23:44:31 -0400 Received: from [199.232.76.173] (port=38363 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MqfFo-0002EH-Ij for bug-gnu-emacs@gnu.org; Wed, 23 Sep 2009 23:44:24 -0400 Received: from fencepost.gnu.org ([140.186.70.10]:51859) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MqfFo-00024P-5p for bug-gnu-emacs@gnu.org; Wed, 23 Sep 2009 23:44:24 -0400 Received: from rgm by fencepost.gnu.org with local (Exim 4.67) (envelope-from ) id 1Mqf0U-0000s3-JX; Wed, 23 Sep 2009 23:28:34 -0400 From: Glenn Morris To: bug-gnu-emacs@gnu.org Subject: window-full-height-p X-Spook: spies Abbas ANC munitions Bin Laden Operation Iraqi X-Ran: J6g8!q8O+opUNIo\]JwgyAA;V~u,6@m@oqLa5Yr#}qU;SpWn{1 User-Agent: Gnus (www.gnus.org), GNU Emacs (www.gnu.org/software/emacs/) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) Severity: wishlist I would like a window-full-height-p function, analogous to window-full-width-p. It is difficult to extract this information from frame-height and window-height for pretty much the same reasons as are used in the Elisp manual to justify the existence of window-full-width-p. The value of frame-height depends on the X-toolkit in use, whether there is a minibuffer, and whether the menu- and tool- bars are on (see bug#4535). For example, a quick grep reveals this code in mh-maybe-show in mh-e/mh-show.el, which is wrong in some circumstances for the reasons explained above: (if (not (= (1+ (window-height)) (frame-height))) ;not horizontally split There seem to be a few similar instances. Perhaps some of them should be using window-safely-shrinkable-p or some other test, but there are some times when I really want to know if a window is full-height. From rudalics@gmx.at Thu Sep 24 00:04:30 2009 Received: (at 4543) by emacsbugs.donarmstrong.com; 24 Sep 2009 07:04:30 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-4.4 required=4.0 tests=AWL,HAS_BUG_NUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with SMTP id n8O74SwK025563 for <4543@emacsbugs.donarmstrong.com>; Thu, 24 Sep 2009 00:04:29 -0700 Received: (qmail invoked by alias); 24 Sep 2009 07:04:22 -0000 Received: from 62-47-53-69.adsl.highway.telekom.at (EHLO [62.47.53.69]) [62.47.53.69] by mail.gmx.net (mp058) with SMTP; 24 Sep 2009 09:04:22 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX198jXddzSp8kYuS6sNu0JTPkhpfWRBnvmKk387pAD p0qG0w7D6zUtTL Message-ID: <4ABB19F5.50908@gmx.at> Date: Thu, 24 Sep 2009 09:04:21 +0200 From: martin rudalics User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Glenn Morris , 4543@debbugs.gnu.org Subject: Re: bug#4543: window-full-height-p References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.82 > I would like a window-full-height-p function, analogous to > window-full-width-p. Would (defun window-full-height-p (&optional window) (unless window (setq window (selected-window))) (= (window-height window) (window-height (frame-root-window (window-frame window))))) fit? martin From rgm@gnu.org Thu Sep 24 23:18:37 2009 Received: (at 4543) by emacsbugs.donarmstrong.com; 25 Sep 2009 06:18:37 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-7.5 required=4.0 tests=AWL,HAS_BUG_NUMBER, X_DEBBUGS_NO_ACK autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from fencepost.gnu.org (fencepost.gnu.org [140.186.70.10]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n8P6IZj6018036 for <4543@emacsbugs.donarmstrong.com>; Thu, 24 Sep 2009 23:18:37 -0700 Received: from rgm by fencepost.gnu.org with local (Exim 4.67) (envelope-from ) id 1Mr48Y-0003GS-RH; Fri, 25 Sep 2009 02:18:34 -0400 From: Glenn Morris To: martin rudalics Cc: 4543@debbugs.gnu.org Subject: Re: bug#4543: window-full-height-p References: <4ABB19F5.50908@gmx.at> X-Spook: rail gun assassinate mindwar BLU-114/B argus Rule Psix X-Ran: Uj2vm?s3@#}zqI$jHwVj:^!QD>=t?Hbzhebd[-6z3}R_34:"#C8bLOM>e11+w9M6"5`.fp X-Hue: white X-Debbugs-No-Ack: yes X-Attribution: GM Date: Fri, 25 Sep 2009 02:18:34 -0400 Message-ID: User-Agent: Gnus (www.gnus.org), GNU Emacs (www.gnu.org/software/emacs/) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii martin rudalics wrote: > Would > > (defun window-full-height-p (&optional window) > (unless window > (setq window (selected-window))) > (= (window-height window) > (window-height (frame-root-window (window-frame window))))) > > fit? Seems to work fine for me, thanks. window-full-width-p has a simple C implementation, but perhaps the same thing is not possible for height? From rudalics@gmx.at Fri Sep 25 00:40:20 2009 Received: (at 4543) by emacsbugs.donarmstrong.com; 25 Sep 2009 07:40:20 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-2.8 required=4.0 tests=AWL,HAS_BUG_NUMBER, RCVD_IN_SBLXBL,RCVD_IN_SBLXBL_CBL autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with SMTP id n8P7eIBd031926 for <4543@emacsbugs.donarmstrong.com>; Fri, 25 Sep 2009 00:40:19 -0700 Received: (qmail invoked by alias); 25 Sep 2009 07:40:12 -0000 Received: from 62-47-44-18.adsl.highway.telekom.at (EHLO [62.47.44.18]) [62.47.44.18] by mail.gmx.net (mp054) with SMTP; 25 Sep 2009 09:40:12 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1/DRShba6LDdQKavGDf6Yg+u/UG1mx1TVuJFZjx/K VpORNCfahwA79A Message-ID: <4ABC73DB.1060308@gmx.at> Date: Fri, 25 Sep 2009 09:40:11 +0200 From: martin rudalics User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Glenn Morris CC: 4543@debbugs.gnu.org Subject: Re: bug#4543: window-full-height-p References: <4ABB19F5.50908@gmx.at> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.6899999999999999 > window-full-width-p has a simple C > implementation, `window-full-width-p' is based on the definition /* Total width of frame F, in columns (characters), including the width used by scroll bars if any. */ #define FRAME_TOTAL_COLS(f) ((f)->total_cols) from frame.h whose semantics I don't understand. Not really simple. > but perhaps the same thing is not possible for height? Hardly. Also I suppose you don't want the return value include the minibuffer height. At least the comment in (if (not (= (1+ (window-height)) (frame-height))) ;not horizontally split seems to suggest that (it confuses horizontally and vertically, BTW). martin From eliz@gnu.org Fri Sep 25 02:30:05 2009 Received: (at 4543) by emacsbugs.donarmstrong.com; 25 Sep 2009 09:30:06 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-2.9 required=4.0 tests=AWL,HAS_BUG_NUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from mtaout6.012.net.il (mtaout6.012.net.il [84.95.2.16]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n8P9U4MS019130 for <4543@emacsbugs.donarmstrong.com>; Fri, 25 Sep 2009 02:30:05 -0700 Received: from conversion-daemon.i-mtaout6.012.net.il by i-mtaout6.012.net.il (HyperSendmail v2007.08) id <0KQI00C00SZS4W00@i-mtaout6.012.net.il> for 4543@emacsbugs.donarmstrong.com; Fri, 25 Sep 2009 12:29:55 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.70.48.81]) by i-mtaout6.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0KQI00GORT1UE5A0@i-mtaout6.012.net.il>; Fri, 25 Sep 2009 12:29:55 +0300 (IDT) Date: Fri, 25 Sep 2009 12:27:58 +0300 From: Eli Zaretskii Subject: Re: bug#4543: window-full-height-p In-reply-to: <4ABC73DB.1060308@gmx.at> X-012-Sender: halo1@inter.net.il To: martin rudalics , 4543@debbugs.gnu.org Cc: rgm@gnu.org Reply-to: Eli Zaretskii Message-id: <83vdj7tlup.fsf@gnu.org> References: <4ABB19F5.50908@gmx.at> <4ABC73DB.1060308@gmx.at> > Date: Fri, 25 Sep 2009 09:40:11 +0200 > From: martin rudalics > Cc: 4543@emacsbugs.donarmstrong.com > > > window-full-width-p has a simple C > > implementation, > > `window-full-width-p' is based on the definition > > /* Total width of frame F, in columns (characters), > including the width used by scroll bars if any. */ > > #define FRAME_TOTAL_COLS(f) ((f)->total_cols) > > from frame.h whose semantics I don't understand. Not really simple. Maybe I can help. What is the difficulty with the semantics of this attribute of a frame? > > but perhaps the same thing is not possible for height? > > Hardly. What's wrong with this (taken from frame.c:frame-parameters) as the frame height: height = (f->new_text_lines ? f->new_text_lines : FRAME_LINES (f)); and then subtract from it the height of the minibuffer window? The C variable `minibuf_window' should give you the Lisp object that holds the minibuffer window, and its `total_lines' attribute should give you the height of that window. Or am I missing something? From rudalics@gmx.at Fri Sep 25 06:00:00 2009 Received: (at 4543) by emacsbugs.donarmstrong.com; 25 Sep 2009 13:00:00 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-2.8 required=4.0 tests=AWL,HAS_BUG_NUMBER, RCVD_IN_SBLXBL,RCVD_IN_SBLXBL_CBL autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with SMTP id n8PCxwnE020906 for <4543@emacsbugs.donarmstrong.com>; Fri, 25 Sep 2009 06:00:00 -0700 Received: (qmail invoked by alias); 25 Sep 2009 12:59:52 -0000 Received: from 62-47-44-18.adsl.highway.telekom.at (EHLO [62.47.44.18]) [62.47.44.18] by mail.gmx.net (mp041) with SMTP; 25 Sep 2009 14:59:52 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX185auIyR+s5QlVbEotaQm9O4GmvlPylZ4HCa7Etf3 qwYZVjJKTN5DDM Message-ID: <4ABCBEC7.70901@gmx.at> Date: Fri, 25 Sep 2009 14:59:51 +0200 From: martin rudalics User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Eli Zaretskii CC: 4543@debbugs.gnu.org, rgm@gnu.org Subject: Re: bug#4543: window-full-height-p References: <4ABB19F5.50908@gmx.at> <4ABC73DB.1060308@gmx.at> <83vdj7tlup.fsf@gnu.org> In-Reply-To: <83vdj7tlup.fsf@gnu.org> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.57 >> `window-full-width-p' is based on the definition >> >> /* Total width of frame F, in columns (characters), >> including the width used by scroll bars if any. */ >> >> #define FRAME_TOTAL_COLS(f) ((f)->total_cols) >> >> from frame.h whose semantics I don't understand. Not really simple. > > Maybe I can help. What is the difficulty with the semantics of this > attribute of a frame? It's merely how this is set in `change_frame_size_1' which does SET_FRAME_COLS (f, newwidth); where #define SET_FRAME_COLS(f, val) \ (FRAME_COLS (f) = (val), \ (f)->total_cols = FRAME_TOTAL_COLS_ARG (f, FRAME_COLS (f))) and #define FRAME_TOTAL_COLS_ARG(f, width) \ ((width) \ + FRAME_SCROLL_BAR_COLS (f) \ + FRAME_FRINGE_COLS (f)) and #define FRAME_SCROLL_BAR_COLS(f) \ (FRAME_HAS_VERTICAL_SCROLL_BARS (f) \ ? FRAME_CONFIG_SCROLL_BAR_COLS (f) \ : 0) etc ... What are the scrollbars of a frame, I'm asking myself. If we define a frame as a collection of windows and frame-width as the width of the widest window in that frame, things are deceptively simple. But the calculations sketched above are a little over my head. > What's wrong with this (taken from frame.c:frame-parameters) as the > frame height: > > height = (f->new_text_lines ? f->new_text_lines : FRAME_LINES (f)); new_text_lines is for a pending size change and zero otherwise. You probably mean text_lines whose precise semantics I don't know - what are canonical characters? > and then subtract from it the height of the minibuffer window? > > The C variable `minibuf_window' should give you the Lisp object that > holds the minibuffer window, and its `total_lines' attribute should > give you the height of that window. Or am I missing something? Then why not use the height of the frame-root-window directly? No need to subtract one value from the other. martin From eliz@gnu.org Fri Sep 25 06:40:59 2009 Received: (at 4543) by emacsbugs.donarmstrong.com; 25 Sep 2009 13:41:00 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-2.9 required=4.0 tests=AWL,HAS_BUG_NUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 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 n8PDewMN028986 for <4543@emacsbugs.donarmstrong.com>; Fri, 25 Sep 2009 06:40:59 -0700 Received: from conversion-daemon.i-mtaout7.012.net.il by i-mtaout7.012.net.il (HyperSendmail v2007.08) id <0KQJ007004MO6200@i-mtaout7.012.net.il> for 4543@emacsbugs.donarmstrong.com; Fri, 25 Sep 2009 16:40:52 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.70.48.81]) by i-mtaout7.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0KQJ00FH34O33730@i-mtaout7.012.net.il>; Fri, 25 Sep 2009 16:40:52 +0300 (IDT) Date: Fri, 25 Sep 2009 16:38:54 +0300 From: Eli Zaretskii Subject: Re: bug#4543: window-full-height-p In-reply-to: <4ABCBEC7.70901@gmx.at> X-012-Sender: halo1@inter.net.il To: martin rudalics Cc: 4543@debbugs.gnu.org, rgm@gnu.org Reply-to: Eli Zaretskii Message-id: <83my4jta8h.fsf@gnu.org> References: <4ABB19F5.50908@gmx.at> <4ABC73DB.1060308@gmx.at> <83vdj7tlup.fsf@gnu.org> <4ABCBEC7.70901@gmx.at> > Date: Fri, 25 Sep 2009 14:59:51 +0200 > From: martin rudalics > CC: 4543@emacsbugs.donarmstrong.com, rgm@gnu.org > > It's merely how this is set in `change_frame_size_1' which does > > SET_FRAME_COLS (f, newwidth); > > where > > #define SET_FRAME_COLS(f, val) \ > (FRAME_COLS (f) = (val), \ > (f)->total_cols = FRAME_TOTAL_COLS_ARG (f, FRAME_COLS (f))) > > and > > #define FRAME_TOTAL_COLS_ARG(f, width) \ > ((width) \ > + FRAME_SCROLL_BAR_COLS (f) \ > + FRAME_FRINGE_COLS (f)) > and > > #define FRAME_SCROLL_BAR_COLS(f) \ > (FRAME_HAS_VERTICAL_SCROLL_BARS (f) \ > ? FRAME_CONFIG_SCROLL_BAR_COLS (f) \ > : 0) > > etc ... Well, maybe I'm missing something, but this seems quite clear to me. SET_FRAME_COLS sets both f->text_cols and f->total_cols, the former counts the width of only the text area of the display, the latter counts the total frame area that includes the scroll bars and the fringe. Both the scroll bar and the fringe may be absent, the most trivial example is the text terminal display. > What are the scrollbars of a frame, I'm asking myself. If we > define a frame as a collection of windows and frame-width as the width > of the widest window in that frame, things are deceptively simple. But > the calculations sketched above are a little over my head. If a frame has scroll bars, they are all of the same size, so counting this on the frame level seems reasonable. > > What's wrong with this (taken from frame.c:frame-parameters) as the > > frame height: > > > > height = (f->new_text_lines ? f->new_text_lines : FRAME_LINES (f)); > > new_text_lines is for a pending size change and zero otherwise. You > probably mean text_lines I don't see any reason not to use new_text_lines as well: first, you will be consistent with frame-parameters (a Good Thing, IMO), and second, your code will work even if redisplay didn't yet kick in. > what are canonical characters? Each line on the display can have its own height, remember? For example, look at a single-window frame whose window displays an "*info*" buffer -- there are several lines that use a larger fonts, and take more screen estate than others. You don't want such a window to screw up window-height or frame-height, do you? So to get this right, Emacs measures these in units of canonical characters, which are characters from the frame's default font. I think the size of this canonical character is given by the font info, but I'm not sure. > > and then subtract from it the height of the minibuffer window? > > > > The C variable `minibuf_window' should give you the Lisp object that > > holds the minibuffer window, and its `total_lines' attribute should > > give you the height of that window. Or am I missing something? > > Then why not use the height of the frame-root-window directly? No need > to subtract one value from the other. Fine, if you can get this efficiently in C. From monnier@iro.umontreal.ca Fri Sep 25 07:37:53 2009 Received: (at 4543) by emacsbugs.donarmstrong.com; 25 Sep 2009 14:37:53 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-2.9 required=4.0 tests=AWL,HAS_BUG_NUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from ironport2-out.pppoe.ca (ironport2-out.teksavvy.com [206.248.154.183]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n8PEbpap007851 for <4543@emacsbugs.donarmstrong.com>; Fri, 25 Sep 2009 07:37:52 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApYGAB9zvEpFpYq6/2dsb2JhbACBUZotuziEHgWHfQ X-IronPort-AV: E=Sophos;i="4.44,451,1249272000"; d="scan'208";a="46596599" Received: from 69-165-138-186.dsl.teksavvy.com (HELO pastel.home) ([69.165.138.186]) by ironport2-out.pppoe.ca with ESMTP; 25 Sep 2009 10:37:26 -0400 Received: by pastel.home (Postfix, from userid 20848) id 679C780B1; Fri, 25 Sep 2009 10:37:26 -0400 (EDT) From: Stefan Monnier To: martin rudalics Cc: 4543@debbugs.gnu.org, Eli Zaretskii Subject: Re: bug#4543: window-full-height-p Message-ID: References: <4ABB19F5.50908@gmx.at> <4ABC73DB.1060308@gmx.at> <83vdj7tlup.fsf@gnu.org> <4ABCBEC7.70901@gmx.at> Date: Fri, 25 Sep 2009 10:37:26 -0400 In-Reply-To: <4ABCBEC7.70901@gmx.at> (martin rudalics's message of "Fri, 25 Sep 2009 14:59:51 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii > #define FRAME_TOTAL_COLS_ARG(f, width) \ > ((width) \ > + FRAME_SCROLL_BAR_COLS (f) \ > + FRAME_FRINGE_COLS (f)) > and > #define FRAME_SCROLL_BAR_COLS(f) \ > (FRAME_HAS_VERTICAL_SCROLL_BARS (f) \ > ? FRAME_CONFIG_SCROLL_BAR_COLS (f) \ > : 0) > etc ... What are the scrollbars of a frame, I'm asking myself. I agree it's rather odd to see such window properties counted for frames. There's probably some ugly counter-balancing calculations in the window-size code. Stefan From rudalics@gmx.at Fri Sep 25 08:04:19 2009 Received: (at 4543) by emacsbugs.donarmstrong.com; 25 Sep 2009 15:04:19 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-4.3 required=4.0 tests=AWL,FOURLA,HAS_BUG_NUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with SMTP id n8PF4Hja012407 for <4543@emacsbugs.donarmstrong.com>; Fri, 25 Sep 2009 08:04:18 -0700 Received: (qmail invoked by alias); 25 Sep 2009 15:04:11 -0000 Received: from 62-47-53-195.adsl.highway.telekom.at (EHLO [62.47.53.195]) [62.47.53.195] by mail.gmx.net (mp050) with SMTP; 25 Sep 2009 17:04:11 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1/LTdECBjnLEacM5hl8B+SYnOEucNJ5dCJ+u4c8i2 /ssZ+ZfFWNMcmK Message-ID: <4ABCDBEA.8060502@gmx.at> Date: Fri, 25 Sep 2009 17:04:10 +0200 From: martin rudalics User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Eli Zaretskii CC: 4543@debbugs.gnu.org, rgm@gnu.org Subject: Re: bug#4543: window-full-height-p References: <4ABB19F5.50908@gmx.at> <4ABC73DB.1060308@gmx.at> <83vdj7tlup.fsf@gnu.org> <4ABCBEC7.70901@gmx.at> <83my4jta8h.fsf@gnu.org> In-Reply-To: <83my4jta8h.fsf@gnu.org> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.63 > Well, maybe I'm missing something, but this seems quite clear to me. > SET_FRAME_COLS sets both f->text_cols and f->total_cols, the former > counts the width of only the text area of the display, the latter > counts the total frame area that includes the scroll bars and the > fringe. It doesn't. Make a frame with two side-by-side windows with scrollbars. Only one scrollbar is counted in f->total_cols. f->total_cols is an artifact whose purpose escapes me so far. And fringe sizes can be set on a per window basis, so counting them seems completely useless. > Both the scroll bar and the fringe may be absent, the most > trivial example is the text terminal display. In that case f->text_cols equals f->total_cols so we can use the former. >> What are the scrollbars of a frame, I'm asking myself. If we >> define a frame as a collection of windows and frame-width as the width >> of the widest window in that frame, things are deceptively simple. But >> the calculations sketched above are a little over my head. > > If a frame has scroll bars, they are all of the same size, so counting > this on the frame level seems reasonable. When I have two side-by-side windows and toggle scroll-bar-mode the frame resizes by exactly the same amount as if it had only one window. So the size available for displaying text within windows changes relatively to the number of side-by-side window I have when toggling scroll-bar mode. This is not reasonable. I'd prefer the frame size to not change at all when I toggle scroll-bar-mode. If it is supposed to change, then all windows would have to change their total width too. >> > What's wrong with this (taken from frame.c:frame-parameters) as the >> > frame height: >> > >> > height = (f->new_text_lines ? f->new_text_lines : FRAME_LINES (f)); >> >> new_text_lines is for a pending size change and zero otherwise. You >> probably mean text_lines > > I don't see any reason not to use new_text_lines as well: first, you > will be consistent with frame-parameters (a Good Thing, IMO), and > second, your code will work even if redisplay didn't yet kick in. The code is supposed to work when no size change is pending and the comment in frame.h says that new_text_lines is zero in that case. >> what are canonical characters? > > Each line on the display can have its own height, remember? For > example, look at a single-window frame whose window displays an > "*info*" buffer -- there are several lines that use a larger fonts, > and take more screen estate than others. You don't want such a window > to screw up window-height or frame-height, do you? Honestly, I never want my frame size to change unless I explicitly ask it to do so. And I never care about the size of my frame measured in lines or columns. What does annoy me is that a maximized Emacs frame changes its size when I toggle scroll-bars or resize the minibuffer. And IIUC this problem is not restricted to Windows. > So to get this right, Emacs measures these in units of canonical > characters, which are characters from the frame's default font. I > think the size of this canonical character is given by the font info, > but I'm not sure. >> Then why not use the height of the frame-root-window directly? No need >> to subtract one value from the other. > > Fine, if you can get this efficiently in C. Why in C? It's a simple lookup written in Elisp. martin From eliz@gnu.org Fri Sep 25 08:55:48 2009 Received: (at 4543) by emacsbugs.donarmstrong.com; 25 Sep 2009 15:55:48 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-2.9 required=4.0 tests=AWL,HAS_BUG_NUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from mtaout2.012.net.il (mtaout2.012.net.il [84.95.2.4]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n8PFtj29022736 for <4543@emacsbugs.donarmstrong.com>; Fri, 25 Sep 2009 08:55:48 -0700 Received: from conversion-daemon.i_mtaout2.012.net.il by i_mtaout2.012.net.il (HyperSendmail v2004.12) id <0KQJ00A00AQHX200@i_mtaout2.012.net.il> for 4543@emacsbugs.donarmstrong.com; Fri, 25 Sep 2009 18:55:37 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.70.48.81]) by i_mtaout2.012.net.il (HyperSendmail v2004.12) with ESMTPA id <0KQJ00ABNAWPSP70@i_mtaout2.012.net.il>; Fri, 25 Sep 2009 18:55:37 +0300 (IDT) Date: Fri, 25 Sep 2009 18:55:40 +0300 From: Eli Zaretskii Subject: Re: bug#4543: window-full-height-p In-reply-to: <4ABCDBEA.8060502@gmx.at> X-012-Sender: halo1@inter.net.il To: martin rudalics Cc: 4543@debbugs.gnu.org, rgm@gnu.org Reply-to: Eli Zaretskii Message-id: <83hburt3wj.fsf@gnu.org> References: <4ABB19F5.50908@gmx.at> <4ABC73DB.1060308@gmx.at> <83vdj7tlup.fsf@gnu.org> <4ABCBEC7.70901@gmx.at> <83my4jta8h.fsf@gnu.org> <4ABCDBEA.8060502@gmx.at> > Date: Fri, 25 Sep 2009 17:04:10 +0200 > From: martin rudalics > CC: 4543@emacsbugs.donarmstrong.com, rgm@gnu.org > > > Well, maybe I'm missing something, but this seems quite clear to me. > > SET_FRAME_COLS sets both f->text_cols and f->total_cols, the former > > counts the width of only the text area of the display, the latter > > counts the total frame area that includes the scroll bars and the > > fringe. > > It doesn't. Make a frame with two side-by-side windows with scrollbars. > Only one scrollbar is counted in f->total_cols. f->total_cols is an > artifact whose purpose escapes me so far. And fringe sizes can be set > on a per window basis, so counting them seems completely useless. Look, you asked to explain the subtleties of the code, and I think I did, as best I could. I hope what the code does is now clear. Whether it makes sense or should be modified, is another matter. From rgm@gnu.org Fri Sep 25 10:23:36 2009 Received: (at 4543) by emacsbugs.donarmstrong.com; 25 Sep 2009 17:23:36 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-7.5 required=4.0 tests=AWL,HAS_BUG_NUMBER, X_DEBBUGS_NO_ACK autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from fencepost.gnu.org (fencepost.gnu.org [140.186.70.10]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n8PHNY4e008260 for <4543@emacsbugs.donarmstrong.com>; Fri, 25 Sep 2009 10:23:36 -0700 Received: from rgm by fencepost.gnu.org with local (Exim 4.67) (envelope-from ) id 1MrEW5-0005nB-3B; Fri, 25 Sep 2009 13:23:33 -0400 From: Glenn Morris To: martin rudalics Cc: 4543@debbugs.gnu.org Subject: Re: bug#4543: window-full-height-p References: <4ABB19F5.50908@gmx.at> <4ABC73DB.1060308@gmx.at> X-Spook: Blowpipe mania Watergate MDA Janet Reno Sundevil X-Ran: <;*KA!Bmo\JCx[|o:4L^4E*9'>qe7&PN!/A;M,rQ;KQwR|sm.Bi$ (martin rudalics's message of "Fri, 25 Sep 2009 09:40:11 +0200") Message-ID: User-Agent: Gnus (www.gnus.org), GNU Emacs (www.gnu.org/software/emacs/) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii I'm sorry, I think I may have caused things to get a bit side-tracked. I would be very happy with your initial solution. martin rudalics wrote: > Also I suppose you don't want the return value include the > minibuffer height. Yes, you are correct. A window in a frame with a minibuffer should still be able to be "full-height". > seems to suggest that (it confuses horizontally and vertically, BTW). I always have to think about which is which. See, to split a window "vertically", you draw a horizontal separator across the middle... From rudalics@gmx.at Fri Sep 25 12:05:32 2009 Received: (at 4543) by emacsbugs.donarmstrong.com; 25 Sep 2009 19:05:32 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-4.3 required=4.0 tests=AWL,HAS_BUG_NUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with SMTP id n8PJ5U4d029295 for <4543@emacsbugs.donarmstrong.com>; Fri, 25 Sep 2009 12:05:31 -0700 Received: (qmail invoked by alias); 25 Sep 2009 19:05:24 -0000 Received: from 62-47-38-104.adsl.highway.telekom.at (EHLO [62.47.38.104]) [62.47.38.104] by mail.gmx.net (mp006) with SMTP; 25 Sep 2009 21:05:24 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX19cflxH481cVpXo/rjFDqJe3Y6gDrvZIG+fa7mPFy BBenF/ChedDijR Message-ID: <4ABD1473.1090005@gmx.at> Date: Fri, 25 Sep 2009 21:05:23 +0200 From: martin rudalics User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Eli Zaretskii CC: 4543@debbugs.gnu.org, rgm@gnu.org Subject: Re: bug#4543: window-full-height-p References: <4ABB19F5.50908@gmx.at> <4ABC73DB.1060308@gmx.at> <83vdj7tlup.fsf@gnu.org> <4ABCBEC7.70901@gmx.at> <83my4jta8h.fsf@gnu.org> <4ABCDBEA.8060502@gmx.at> <83hburt3wj.fsf@gnu.org> In-Reply-To: <83hburt3wj.fsf@gnu.org> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.82 > Look, you asked to explain the subtleties of the code, and I think I > did, as best I could. I hope what the code does is now clear. I was impolite. Please accept my apologies and my belated thanks for your explanations. > Whether it makes sense or should be modified, is another matter. Indeed. martin From rudalics@gmx.at Fri Sep 25 12:05:48 2009 Received: (at 4543) by emacsbugs.donarmstrong.com; 25 Sep 2009 19:05:49 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-4.3 required=4.0 tests=AWL,HAS_BUG_NUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with SMTP id n8PJ5kEc029321 for <4543@emacsbugs.donarmstrong.com>; Fri, 25 Sep 2009 12:05:48 -0700 Received: (qmail invoked by alias); 25 Sep 2009 19:05:40 -0000 Received: from 62-47-38-104.adsl.highway.telekom.at (EHLO [62.47.38.104]) [62.47.38.104] by mail.gmx.net (mp055) with SMTP; 25 Sep 2009 21:05:40 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX184IqUNM5k4Xnbk835qZmlPdBZqsI1yslVC11Vd5U UN6/S/8FIlqhvX Message-ID: <4ABD1484.7020900@gmx.at> Date: Fri, 25 Sep 2009 21:05:40 +0200 From: martin rudalics User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Glenn Morris CC: 4543@debbugs.gnu.org Subject: Re: bug#4543: window-full-height-p References: <4ABB19F5.50908@gmx.at> <4ABC73DB.1060308@gmx.at> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.79 > I always have to think about which is which. See, to split a window > "vertically", you draw a horizontal separator across the middle... These terms _are_ confusing. But I'd also like to get rid of the term `split-window'. What a user wants is a new window below or right of some specified one or maybe at the top or the bottom of the frame. I'd prefer `create-window' with a window, size, and placement argument. martin From monnier@IRO.UMontreal.CA Fri Sep 25 13:10:47 2009 Received: (at 4543) by emacsbugs.donarmstrong.com; 25 Sep 2009 20:10:47 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-4.1 required=4.0 tests=AWL,HAS_BUG_NUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from chene.dit.umontreal.ca (chene.dit.umontreal.ca [132.204.246.20]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n8PKAhJx007202 for <4543@emacsbugs.donarmstrong.com>; Fri, 25 Sep 2009 13:10:45 -0700 Received: from faina.iro.umontreal.ca (faina.iro.umontreal.ca [132.204.26.177]) by chene.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id n8PKAdZh011955; Fri, 25 Sep 2009 16:10:39 -0400 Received: by faina.iro.umontreal.ca (Postfix, from userid 20848) id 079083A227; Fri, 25 Sep 2009 16:10:39 -0400 (EDT) From: Stefan Monnier To: Glenn Morris Cc: 4543@debbugs.gnu.org, martin rudalics Subject: Re: bug#4543: window-full-height-p Message-ID: References: <4ABB19F5.50908@gmx.at> <4ABC73DB.1060308@gmx.at> Date: Fri, 25 Sep 2009 16:10:38 -0400 In-Reply-To: (Glenn Morris's message of "Fri, 25 Sep 2009 13:23:32 -0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 1 Rules triggered RV3371=0 >> seems to suggest that (it confuses horizontally and vertically, BTW). > I always have to think about which is which. See, to split a window > "vertically", you draw a horizontal separator across the middle... It's worse for me: even thinking doesn't help me resolve the ambiguity, because I think both interpretations make sense. So I always end up doing C-h k C-x 2 to see what that operation (which I know well) is called. It might be worthwhile trying to come up with a different terminology that doesn't suffer from that ambiguity. E.g. use "left-right" for one and "up-down" for the other. Stefan From monnier@IRO.UMontreal.CA Fri Sep 25 13:16:54 2009 Received: (at 4543) by emacsbugs.donarmstrong.com; 25 Sep 2009 20:16:54 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-4.0 required=4.0 tests=AWL,FOURLA,HAS_BUG_NUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from chene.dit.umontreal.ca (chene.dit.umontreal.ca [132.204.246.20]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n8PKGpSm007883 for <4543@emacsbugs.donarmstrong.com>; Fri, 25 Sep 2009 13:16:53 -0700 Received: from faina.iro.umontreal.ca (faina.iro.umontreal.ca [132.204.26.177]) by chene.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id n8PKGlPC013416; Fri, 25 Sep 2009 16:16:48 -0400 Received: by faina.iro.umontreal.ca (Postfix, from userid 20848) id E6E933A227; Fri, 25 Sep 2009 16:16:46 -0400 (EDT) From: Stefan Monnier To: martin rudalics Cc: 4543@debbugs.gnu.org, Eli Zaretskii Subject: Re: bug#4543: window-full-height-p Message-ID: References: <4ABB19F5.50908@gmx.at> <4ABC73DB.1060308@gmx.at> <83vdj7tlup.fsf@gnu.org> <4ABCBEC7.70901@gmx.at> <83my4jta8h.fsf@gnu.org> <4ABCDBEA.8060502@gmx.at> Date: Fri, 25 Sep 2009 16:16:46 -0400 In-Reply-To: <4ABCDBEA.8060502@gmx.at> (martin rudalics's message of "Fri, 25 Sep 2009 17:04:10 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 1 Rules triggered RV3371=0 > When I have two side-by-side windows and toggle scroll-bar-mode the > frame resizes by exactly the same amount as if it had only one window. > So the size available for displaying text within windows changes > relatively to the number of side-by-side window I have when toggling > scroll-bar mode. This is not reasonable. I'd prefer the frame size to > not change at all when I toggle scroll-bar-mode. If it is supposed to > change, then all windows would have to change their total width too. Yes, that's clearly not the right behavior. If you want to change things so that the scrollbar&fringes are counted in "windows" but not in "frames" to try and avoid these problems, feel free to try. > Honestly, I never want my frame size to change unless I explicitly ask > it to do so. And I never care about the size of my frame measured in > lines or columns. What does annoy me is that a maximized Emacs frame > changes its size when I toggle scroll-bars or resize the minibuffer. Agreed. The fact that sizes are counted in "characters" is also undesirable for GUI frames. At some point I suggested to just force the "canonical character size" to always be 1x1, but IIUC this would be inefficient. IIRC, Kim Storm had done some preliminary work towards getting rid of this "canonical character size" issue. I'd be a good change (would solve several minor problems we have, with wasted pixels here and there). Stefan From rudalics@gmx.at Sat Sep 26 02:45:50 2009 Received: (at 4543) by emacsbugs.donarmstrong.com; 26 Sep 2009 09:45:50 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-4.3 required=4.0 tests=AWL,HAS_BUG_NUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with SMTP id n8Q9jmf6004574 for <4543@emacsbugs.donarmstrong.com>; Sat, 26 Sep 2009 02:45:50 -0700 Received: (qmail invoked by alias); 26 Sep 2009 09:45:42 -0000 Received: from 62-47-36-64.adsl.highway.telekom.at (EHLO [62.47.36.64]) [62.47.36.64] by mail.gmx.net (mp069) with SMTP; 26 Sep 2009 11:45:42 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1981G0R3eV8rAfHJ39dhMiUizHLT8pFwy/aUVtWMC eybViFxUJ/8Ee2 Message-ID: <4ABDE2C5.2070808@gmx.at> Date: Sat, 26 Sep 2009 11:45:41 +0200 From: martin rudalics User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Stefan Monnier CC: 4543@debbugs.gnu.org Subject: Re: bug#4543: window-full-height-p References: <4ABB19F5.50908@gmx.at> <4ABC73DB.1060308@gmx.at> <83vdj7tlup.fsf@gnu.org> <4ABCBEC7.70901@gmx.at> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.6 Stefan Monnier schrieb: >> #define FRAME_TOTAL_COLS_ARG(f, width) \ >> ((width) \ >> + FRAME_SCROLL_BAR_COLS (f) \ >> + FRAME_FRINGE_COLS (f)) >> and > >> #define FRAME_SCROLL_BAR_COLS(f) \ >> (FRAME_HAS_VERTICAL_SCROLL_BARS (f) \ >> ? FRAME_CONFIG_SCROLL_BAR_COLS (f) \ >> : 0) > >> etc ... What are the scrollbars of a frame, I'm asking myself. > > I agree it's rather odd to see such window properties counted > for frames. There's probably some ugly counter-balancing calculations > in the window-size code. I doubt that. The window-size code handles scroll bars and fringes on a per window/buffer basis and fits them (recursively) within the size it's given by change_frame_size_1 as set_window_width (FRAME_ROOT_WINDOW (f), new_frame_total_cols, 2); So whether and how scroll bars and/or fringes are displayed ignores anything done in change_frame_size_1. 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. I'm not sure, however, whether text-only terminals inherently rely on these calculations. So the question I essentially ask is whether the number of total columns of a frame's root-window invariantly equals the width of that frame over all possible terminals. martin From rudalics@gmx.at Sat Sep 26 02:46:03 2009 Received: (at 4543) by emacsbugs.donarmstrong.com; 26 Sep 2009 09:46:03 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-4.3 required=4.0 tests=AWL,HAS_BUG_NUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with SMTP id n8Q9k1Cv004584 for <4543@emacsbugs.donarmstrong.com>; Sat, 26 Sep 2009 02:46:03 -0700 Received: (qmail invoked by alias); 26 Sep 2009 09:45:55 -0000 Received: from 62-47-36-64.adsl.highway.telekom.at (EHLO [62.47.36.64]) [62.47.36.64] by mail.gmx.net (mp071) with SMTP; 26 Sep 2009 11:45:55 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1/f3oYCDnvfMkmD3EB6cW5ARAN9VAHEaUMHsTNK+r qov8np9+blTuTa Message-ID: <4ABDE2D2.9070904@gmx.at> Date: Sat, 26 Sep 2009 11:45:54 +0200 From: martin rudalics User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Stefan Monnier CC: 4543@debbugs.gnu.org Subject: Re: bug#4543: window-full-height-p References: <4ABB19F5.50908@gmx.at> <4ABC73DB.1060308@gmx.at> <83vdj7tlup.fsf@gnu.org> <4ABCBEC7.70901@gmx.at> <83my4jta8h.fsf@gnu.org> <4ABCDBEA.8060502@gmx.at> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.74 >> When I have two side-by-side windows and toggle scroll-bar-mode the >> frame resizes by exactly the same amount as if it had only one window. >> So the size available for displaying text within windows changes >> relatively to the number of side-by-side window I have when toggling >> scroll-bar mode. This is not reasonable. I'd prefer the frame size to >> not change at all when I toggle scroll-bar-mode. If it is supposed to >> change, then all windows would have to change their total width too. > > Yes, that's clearly not the right behavior. If you want to change > things so that the scrollbar&fringes are counted in "windows" but not in > "frames" to try and avoid these problems, feel free to try. Scroll bars and fringes _are_ counted in the "windows" code and do not affect the frame size. Otherwise changing scroll bars in a single window frame would resize the frame as well, just try (set-window-scroll-bars nil 200 'right) and see that the frame width remains alone. So the only problem I see is with change_frame_size. martin From eliz@gnu.org Sat Sep 26 04:26:44 2009 Received: (at 4543) by emacsbugs.donarmstrong.com; 26 Sep 2009 11:26:45 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-4.7 required=4.0 tests=AWL,HAS_BUG_NUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from mtaout3.012.net.il (mtaout3.012.net.il [84.95.2.7]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n8QBQhcS021818 for <4543@emacsbugs.donarmstrong.com>; Sat, 26 Sep 2009 04:26:44 -0700 Received: from conversion-daemon.i_mtaout3.012.net.il by i_mtaout3.012.net.il (HyperSendmail v2004.12) id <0KQK00F00T3INZ00@i_mtaout3.012.net.il> for 4543@emacsbugs.donarmstrong.com; Sat, 26 Sep 2009 14:26:36 +0300 (IDT) Received: from HOME-C4E4A596F7 ([77.126.56.156]) by i_mtaout3.012.net.il (HyperSendmail v2004.12) with ESMTPA id <0KQK00FMYT4CJ9N0@i_mtaout3.012.net.il>; Sat, 26 Sep 2009 14:26:36 +0300 (IDT) Date: Sat, 26 Sep 2009 14:28:39 +0300 From: Eli Zaretskii Subject: Re: bug#4543: window-full-height-p In-reply-to: <4ABDE2C5.2070808@gmx.at> X-012-Sender: halo1@inter.net.il To: martin rudalics , 4543@debbugs.gnu.org Cc: monnier@IRO.UMontreal.CA Reply-to: Eli Zaretskii Message-id: <83vdj6rllk.fsf@gnu.org> References: <4ABB19F5.50908@gmx.at> <4ABC73DB.1060308@gmx.at> <83vdj7tlup.fsf@gnu.org> <4ABCBEC7.70901@gmx.at> <4ABDE2C5.2070808@gmx.at> > Date: Sat, 26 Sep 2009 11:45:41 +0200 > From: martin rudalics > Cc: 4543@emacsbugs.donarmstrong.com > > 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. 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? > I'm not sure, however, whether text-only terminals inherently rely > on these calculations. So the question I essentially ask is whether > the number of total columns of a frame's root-window invariantly > equals the width of that frame over all possible terminals. I think it does, yes. In any case, the code in change_frame_size_1 _is_ run on text-only terminals (or should I say for frames on text-only terminals, since we have multi-tty now). From rudalics@gmx.at Sat Sep 26 06:42:06 2009 Received: (at 4543) by emacsbugs.donarmstrong.com; 26 Sep 2009 13:42:07 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-3.7 required=4.0 tests=AWL,FOURLA,HAS_BUG_NUMBER, MONOTONE_WORDS_2_15 autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with SMTP id n8QDg4l4010783 for <4543@emacsbugs.donarmstrong.com>; Sat, 26 Sep 2009 06:42:06 -0700 Received: (qmail invoked by alias); 26 Sep 2009 13:41:58 -0000 Received: from 62-47-36-64.adsl.highway.telekom.at (EHLO [62.47.36.64]) [62.47.36.64] by mail.gmx.net (mp026) with SMTP; 26 Sep 2009 15:41:58 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX18ub85kvYwu360YgWsUQXFiBb7eq7c0OuoF6qh6lZ EgRV+LrQz2L6un Message-ID: <4ABE1A25.7050909@gmx.at> Date: Sat, 26 Sep 2009 15:41:57 +0200 From: martin rudalics User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Eli Zaretskii CC: 4543@debbugs.gnu.org, monnier@IRO.UMontreal.CA Subject: Re: bug#4543: window-full-height-p 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> In-Reply-To: <83vdj6rllk.fsf@gnu.org> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.57 > 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. >> I'm not sure, however, whether text-only terminals inherently rely >> on these calculations. So the question I essentially ask is whether >> the number of total columns of a frame's root-window invariantly >> equals the width of that frame over all possible terminals. > > I think it does, yes. In any case, the code in change_frame_size_1 > _is_ run on text-only terminals (or should I say for frames on > text-only terminals, since we have multi-tty now). Fine. I wasn't entirely sure about dos_set_window_size (&newheight, &newwidth); which IIUC does adjust the width value via *rows = ScreenRows (); so this eventually does get related back to the frame's root window. martin From eliz@gnu.org Sat Sep 26 09:26:01 2009 Received: (at 4543) by emacsbugs.donarmstrong.com; 26 Sep 2009 16:26:02 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-4.7 required=4.0 tests=AWL,FOURLA,HAS_BUG_NUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 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 n8QGQ0SA005042 for <4543@emacsbugs.donarmstrong.com>; Sat, 26 Sep 2009 09:26:01 -0700 Received: from conversion-daemon.i-mtaout7.012.net.il by i-mtaout7.012.net.il (HyperSendmail v2007.08) id <0KQL00F006VXQZ00@i-mtaout7.012.net.il> for 4543@emacsbugs.donarmstrong.com; Sat, 26 Sep 2009 19:25:48 +0300 (IDT) Received: from HOME-C4E4A596F7 ([77.126.56.156]) by i-mtaout7.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0KQL000HA6YZ9QB0@i-mtaout7.012.net.il>; Sat, 26 Sep 2009 19:25:48 +0300 (IDT) Date: Sat, 26 Sep 2009 19:27:50 +0300 From: Eli Zaretskii Subject: Re: bug#4543: window-full-height-p In-reply-to: <4ABE1A25.7050909@gmx.at> X-012-Sender: halo1@inter.net.il To: martin rudalics Cc: 4543@debbugs.gnu.org, monnier@IRO.UMontreal.CA Reply-to: Eli Zaretskii Message-id: <83pr9dsmbd.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> > Date: Sat, 26 Sep 2009 15:41:57 +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. > >> I'm not sure, however, whether text-only terminals inherently rely > >> on these calculations. So the question I essentially ask is whether > >> the number of total columns of a frame's root-window invariantly > >> equals the width of that frame over all possible terminals. > > > > I think it does, yes. In any case, the code in change_frame_size_1 > > _is_ run on text-only terminals (or should I say for frames on > > text-only terminals, since we have multi-tty now). > > Fine. I wasn't entirely sure about > > dos_set_window_size (&newheight, &newwidth); > > which IIUC does adjust the width value via > > *rows = ScreenRows (); > > so this eventually does get related back to the frame's root window. That's true, but only if the original newheight or newwidth are not supported by the underlying video hardware. If they are supported, then they are left at their computed values. And the DOS display does not support scroll bars anyway. From rudalics@gmx.at Sat Sep 26 12:01:49 2009 Received: (at 4543) by emacsbugs.donarmstrong.com; 26 Sep 2009 19:01:49 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-4.3 required=4.0 tests=AWL,HAS_BUG_NUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with SMTP id n8QJ1lH5030768 for <4543@emacsbugs.donarmstrong.com>; Sat, 26 Sep 2009 12:01:48 -0700 Received: (qmail invoked by alias); 26 Sep 2009 19:01:40 -0000 Received: from 62-47-38-202.adsl.highway.telekom.at (EHLO [62.47.38.202]) [62.47.38.202] by mail.gmx.net (mp011) with SMTP; 26 Sep 2009 21:01:40 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1+gpF11A0+grK91depmD34USJ0xAZR8j94vywSua6 Sf53uXuts5Zrfz Message-ID: <4ABE6510.90508@gmx.at> Date: Sat, 26 Sep 2009 21:01:36 +0200 From: martin rudalics User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Eli Zaretskii CC: 4543@debbugs.gnu.org, monnier@IRO.UMontreal.CA Subject: Re: bug#4543: window-full-height-p 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> In-Reply-To: <83pr9dsmbd.fsf@gnu.org> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.6 >> > 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. Or the fact that setting `scroll-bar-mode' may trigger frame-resizing in the first place. martin From eliz@gnu.org Sat Sep 26 13:15:21 2009 Received: (at 4543) by emacsbugs.donarmstrong.com; 26 Sep 2009 20:15:22 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-4.7 required=4.0 tests=AWL,HAS_BUG_NUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 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 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) 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) Date: Sat, 26 Sep 2009 23:17:16 +0300 From: Eli Zaretskii Subject: Re: bug#4543: window-full-height-p In-reply-to: <4ABE6510.90508@gmx.at> X-012-Sender: halo1@inter.net.il To: martin rudalics Cc: 4543@debbugs.gnu.org, monnier@IRO.UMontreal.CA Reply-to: Eli Zaretskii 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> > 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. From rudalics@gmx.at Sun Sep 27 00:49:38 2009 Received: (at 4543) by emacsbugs.donarmstrong.com; 27 Sep 2009 07:49:38 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-4.2 required=4.0 tests=AWL,FOURLA,HAS_BUG_NUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with SMTP id n8R7naCa016783 for <4543@emacsbugs.donarmstrong.com>; Sun, 27 Sep 2009 00:49:38 -0700 Received: (qmail invoked by alias); 27 Sep 2009 07:49:30 -0000 Received: from 62-47-60-3.adsl.highway.telekom.at (EHLO [62.47.60.3]) [62.47.60.3] by mail.gmx.net (mp017) with SMTP; 27 Sep 2009 09:49:30 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX19mhKZL8TNmEDHM+oblgV8C7/9QZJw0uztOQbQZBp fVehdJzmRJ28VM Message-ID: <4ABF1908.9090804@gmx.at> Date: Sun, 27 Sep 2009 09:49:28 +0200 From: martin rudalics User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Eli Zaretskii CC: 4543@debbugs.gnu.org, monnier@IRO.UMontreal.CA Subject: Re: bug#4543: window-full-height-p 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> <83k4zlsboz.fsf@gnu.org> In-Reply-To: <83k4zlsboz.fsf@gnu.org> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.66 > We are looping: the more complex window configurations are irrelevant > for the root window, I think. Because I tried to come up with a simple, easily repeatable example that does not need a more complex configuration. > What I'm missing is how the code fragments you show are related to the > problematic behavior when `scroll-bar-mode' is toggled. Since I never understood the mechanism handling frame parameters I can only conjecture that it's x_set_scroll_bar_width (the handler for the scroll-bar-width parameter) calling change_frame_size which causes this. But the basic problem is that handling scroll bar sizes on the frame level cannot make sense because the mechanism doing that wouldn't know (1) whether an individual window has scrollbars and how large they are, (2) the number of side-by-side windows in any horizontal bisection of the frame. Even if that knowledge were present, there still remain configurations where adjusting the frame size can't DTRT. Consider the following two examples with slightly "more complex configurations": Example 1: Split the window of a single-window frame into two windows one above the other and remove the scrollbar in _one_ of the emanating windows. Toggle scroll-bar-mode. Whatever toggling does to adjust the frame size it will be wrong for one of the windows. Example 2: Split the window of a single-window frame into two windows one above the other. Now split the upper window into two side-by-side windows. If you now toggle scroll-bar-mode and try to correctly account for the scrollbars in the side-by-side windows, the lower window will grow or shrink by an additional column. martin From rgm@gnu.org Fri Oct 2 00:12:32 2009 Received: (at 4543) by emacsbugs.donarmstrong.com; 2 Oct 2009 07:12:32 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-7.5 required=4.0 tests=AWL,HAS_BUG_NUMBER, X_DEBBUGS_NO_ACK autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from fencepost.gnu.org (fencepost.gnu.org [140.186.70.10]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n927CV9s023832 for <4543@emacsbugs.donarmstrong.com>; Fri, 2 Oct 2009 00:12:32 -0700 Received: from rgm by fencepost.gnu.org with local (Exim 4.67) (envelope-from ) id 1MtcJa-0001TP-7U; Fri, 02 Oct 2009 03:12:30 -0400 From: Glenn Morris To: 4543@debbugs.gnu.org Cc: martin rudalics Subject: Re: bug#4543: window-full-height-p References: <4ABB19F5.50908@gmx.at> X-Spook: counter terrorism Al-Qaeda computer terrorism Montenegro X-Ran: ,=\x>dzbs?fN9}wW6K.EQ`yEKs_?qKomuw^QH]V1g5GAq$nh,i!yNjZ'!joawFWLqMQ;!% X-Hue: blue X-Debbugs-No-Ack: yes X-Attribution: GM Date: Fri, 02 Oct 2009 03:12:30 -0400 Message-ID: User-Agent: Gnus (www.gnus.org), GNU Emacs (www.gnu.org/software/emacs/) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii > martin rudalics wrote: >> (defun window-full-height-p (&optional window) >> (unless window >> (setq window (selected-window))) >> (= (window-height window) >> (window-height (frame-root-window (window-frame window))))) Please could this be installed? From rudalics@gmx.at Fri Oct 2 01:39:42 2009 Received: (at 4543) by emacsbugs.donarmstrong.com; 2 Oct 2009 08:39:43 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-4.2 required=4.0 tests=AWL,FOURLA,HAS_BUG_NUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with SMTP id n928dejD004074 for <4543@emacsbugs.donarmstrong.com>; Fri, 2 Oct 2009 01:39:42 -0700 Received: (qmail invoked by alias); 02 Oct 2009 08:39:34 -0000 Received: from 62-47-63-97.adsl.highway.telekom.at (EHLO [62.47.63.97]) [62.47.63.97] by mail.gmx.net (mp056) with SMTP; 02 Oct 2009 10:39:34 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX19DESobXa1DqQUlAQVx2i+TR0wdKp9X2DyxMmzMRY BDAwSCEmZYvPbI Message-ID: <4AC5BC45.4060406@gmx.at> Date: Fri, 02 Oct 2009 10:39:33 +0200 From: martin rudalics User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Glenn Morris CC: 4543@debbugs.gnu.org Subject: Re: bug#4543: window-full-height-p References: <4ABB19F5.50908@gmx.at> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.52 >>> (defun window-full-height-p (&optional window) >>> (unless window >>> (setq window (selected-window))) >>> (= (window-height window) >>> (window-height (frame-root-window (window-frame window))))) > > Please could this be installed? I have a number of problems with this: (1) The name is problematic. Note that `window-full-width-p' has no such problem because when it returns t the window is as wide as the containing frame. (2) It might give unexpected results when invoked with the minibuffer window as argument. Again `window-full-width-p' has no such problems. (3) It must be rewritten as soon as someone implements horizontal scrollbars ;-) Currently, getting (and setting) the sizes of windows (or frames) is a mess. Consider, for example, `split-window': If you use `window-width' on its argument WINDOW in order to pre-calculate the SIZE argument you almost certainly end up doing the wrong thing. Personally, I use a function `window-size' to return the total size of a window thus avoiding such confusions: DEFUN ("window-size", Fwindow_size, Swindow_size, 0, 2, 0, doc: /* Return total number of lines of WINDOW. WINDOW defaults to the selected window. The return values includes any header- or mode-line. Optional argument HORIZONTAL non-nil means return total number of columns of WINDOW. In this case the return value includes any scroll-bars of WINDOW. */) (window, horizontal) Lisp_Object window, horizontal; { if (!NILP (horizontal)) return decode_any_window (window)->total_cols; else return decode_any_window (window)->total_lines; } Anyway, if you can think of a better name (which should resolve (1) and (2)) and a comment wrt (3) feel free to install it. I'm currently a bit reluctant to install because my internet connection has been unreliable over the past weeks. martin From monnier@iro.umontreal.ca Fri Oct 2 06:30:38 2009 Received: (at 4543) by emacsbugs.donarmstrong.com; 2 Oct 2009 13:30:38 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-4.6 required=4.0 tests=AWL,FOURLA,HAS_BUG_NUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from ironport2-out.pppoe.ca (ironport2-out.teksavvy.com [206.248.154.181]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n92DUaBt024037 for <4543@emacsbugs.donarmstrong.com>; Fri, 2 Oct 2009 06:30:38 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsAEADadxUpFxIJG/2dsb2JhbACBUdYShCwEhx0 X-IronPort-AV: E=Sophos;i="4.44,494,1249272000"; d="scan'208";a="46984509" Received: from 69-196-130-70.dsl.teksavvy.com (HELO pastel.home) ([69.196.130.70]) by ironport2-out.pppoe.ca with ESMTP; 02 Oct 2009 09:30:30 -0400 Received: by pastel.home (Postfix, from userid 20848) id DA3E08109; Fri, 2 Oct 2009 09:30:29 -0400 (EDT) From: Stefan Monnier To: martin rudalics Cc: 4543@debbugs.gnu.org, Glenn Morris Subject: Re: bug#4543: window-full-height-p Message-ID: References: <4ABB19F5.50908@gmx.at> <4AC5BC45.4060406@gmx.at> Date: Fri, 02 Oct 2009 09:30:29 -0400 In-Reply-To: <4AC5BC45.4060406@gmx.at> (martin rudalics's message of "Fri, 02 Oct 2009 10:39:33 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii >>>> (defun window-full-height-p (&optional window) >>>> (unless window >>>> (setq window (selected-window))) >>>> (= (window-height window) >>>> (window-height (frame-root-window (window-frame window))))) >> >> Please could this be installed? > I have a number of problems with this: > (1) The name is problematic. Note that `window-full-width-p' has no > such problem because when it returns t the window is as wide as the > containing frame. > (2) It might give unexpected results when invoked with the minibuffer > window as argument. Again `window-full-width-p' has no such problems. I think the name is OK, but the docstring needs to clearly explain what is the intended behavior (which, I must say, I do not know, but I guess it's something like "the frame is not split top-down", except we're talking about a window). It's more important to make sure that the docstring is clear and describes a useful behavior, than to make sure it describes the actual behavior of its current implementation. > (3) It must be rewritten as soon as someone implements horizontal > scrollbars ;-) That's OK: this code is (now) available for 0 efforts, so rewriting it wouldn't mean that much effort has been wasted. > Personally, I use a function `window-size' to return the total size of a > window thus avoiding such confusions: > DEFUN ("window-size", Fwindow_size, Swindow_size, 0, 2, 0, > doc: /* Return total number of lines of WINDOW. > WINDOW defaults to the selected window. The return values includes any > header- or mode-line. Optional argument HORIZONTAL non-nil means return > total number of columns of WINDOW. In this case the return value > includes any scroll-bars of WINDOW. */) > (window, horizontal) > Lisp_Object window, horizontal; > { > if (!NILP (horizontal)) > return decode_any_window (window)->total_cols; > else > return decode_any_window (window)->total_lines; > } Seems reasonable. Where do you use it? Stefan From rudalics@gmx.at Fri Oct 2 08:56:12 2009 Received: (at 4543) by emacsbugs.donarmstrong.com; 2 Oct 2009 15:56:13 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-4.2 required=4.0 tests=AWL,FOURLA,HAS_BUG_NUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with SMTP id n92FuAvh014751 for <4543@emacsbugs.donarmstrong.com>; Fri, 2 Oct 2009 08:56:12 -0700 Received: (qmail invoked by alias); 02 Oct 2009 15:56:04 -0000 Received: from 62-47-36-205.adsl.highway.telekom.at (EHLO [62.47.36.205]) [62.47.36.205] by mail.gmx.net (mp001) with SMTP; 02 Oct 2009 17:56:04 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1/DVOZ1g0rD6HX6pB91vEkwRSrGxW6yJB7ULmyR3z pG9Izj0Vv+2A/R Message-ID: <4AC62293.6010403@gmx.at> Date: Fri, 02 Oct 2009 17:56:03 +0200 From: martin rudalics User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Stefan Monnier CC: 4543@debbugs.gnu.org, Glenn Morris Subject: Re: bug#4543: window-full-height-p References: <4ABB19F5.50908@gmx.at> <4AC5BC45.4060406@gmx.at> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.53 > I think the name is OK, but the docstring needs to clearly explain what > is the intended behavior (which, I must say, I do not know, but I guess > it's something like "the frame is not split top-down", except we're > talking about a window). It's more important to make sure that > the docstring is clear and describes a useful behavior, than to make > sure it describes the actual behavior of its current implementation. I could come up with something like (defun window-full-height-p (&optional window) "Return t if WINDOW is as high as the root window of its frame. WINDOW defaults to the selected window. This function returns t if and only if there is no other window above WINDOW and there is either no other window below WINDOW or the minibuffer window appears right below WINDOW." (unless window (setq window (selected-window))) (= (window-height window) (window-height (frame-root-window (window-frame window))))) but maybe Glenn has a better idea. >> Personally, I use a function `window-size' to return the total size of a >> window thus avoiding such confusions: > >> DEFUN ("window-size", Fwindow_size, Swindow_size, 0, 2, 0, >> doc: /* Return total number of lines of WINDOW. >> WINDOW defaults to the selected window. The return values includes any >> header- or mode-line. Optional argument HORIZONTAL non-nil means return >> total number of columns of WINDOW. In this case the return value >> includes any scroll-bars of WINDOW. */) >> (window, horizontal) >> Lisp_Object window, horizontal; >> { >> if (!NILP (horizontal)) >> return decode_any_window (window)->total_cols; >> else >> return decode_any_window (window)->total_lines; >> } > > Seems reasonable. Where do you use it? Most everywhere. There's no sense reasoning about fringes, margins or scrollbars when reasoning about sizes of windows or frames. The only function I could think of where counting text columns might have been useful is `split-window' ... martin From rgm@gnu.org Fri Oct 2 11:37:23 2009 Received: (at 4543) by emacsbugs.donarmstrong.com; 2 Oct 2009 18:37:23 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-7.5 required=4.0 tests=AWL,HAS_BUG_NUMBER, X_DEBBUGS_NO_ACK autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from fencepost.gnu.org (fencepost.gnu.org [140.186.70.10]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n92IbLxY007488 for <4543@emacsbugs.donarmstrong.com>; Fri, 2 Oct 2009 11:37:23 -0700 Received: from rgm by fencepost.gnu.org with local (Exim 4.67) (envelope-from ) id 1Mtn0K-0004lr-Kr; Fri, 02 Oct 2009 14:37:20 -0400 From: Glenn Morris To: martin rudalics Cc: Stefan Monnier , 4543@debbugs.gnu.org Subject: Re: bug#4543: window-full-height-p References: <4ABB19F5.50908@gmx.at> <4AC5BC45.4060406@gmx.at> <4AC62293.6010403@gmx.at> X-Spook: Rubin colonel clones wire transfer rs9512c electronic X-Ran: 98rfUc{S[lMhcICvH}+oP:]((ECXVT6UYx9E<6M42*g\b8\VCz8E~Ox"<_kBMGI@MG[:I( X-Hue: cyan X-Debbugs-No-Ack: yes X-Attribution: GM Date: Fri, 02 Oct 2009 14:37:20 -0400 In-Reply-To: <4AC62293.6010403@gmx.at> (martin rudalics's message of "Fri, 02 Oct 2009 17:56:03 +0200") Message-ID: User-Agent: Gnus (www.gnus.org), GNU Emacs (www.gnu.org/software/emacs/) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii martin rudalics wrote: > (defun window-full-height-p (&optional window) > "Return t if WINDOW is as high as the root window of its frame. > WINDOW defaults to the selected window. > > This function returns t if and only if there is no other window > above WINDOW and there is either no other window below WINDOW or > the minibuffer window appears right below WINDOW." I would just say something like: "Return non-nil if WINDOW is not the result of a vertical split. WINDOW defaults to the selected window. (This function is not appropriate for minibuffers.)" From rudalics@gmx.at Sat Oct 3 01:20:21 2009 Received: (at 4543) by emacsbugs.donarmstrong.com; 3 Oct 2009 08:20:22 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-4.3 required=4.0 tests=AWL,HAS_BUG_NUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with SMTP id n938KJcL008871 for <4543@emacsbugs.donarmstrong.com>; Sat, 3 Oct 2009 01:20:21 -0700 Received: (qmail invoked by alias); 03 Oct 2009 08:20:13 -0000 Received: from 62-47-52-87.adsl.highway.telekom.at (EHLO [62.47.52.87]) [62.47.52.87] by mail.gmx.net (mp017) with SMTP; 03 Oct 2009 10:20:13 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX19Pn9ZbAHxPs60xaO36bats06a2zJorKls0GMUgV5 Mq4UBmRpXhJfQo Message-ID: <4AC7093C.5050200@gmx.at> Date: Sat, 03 Oct 2009 10:20:12 +0200 From: martin rudalics User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Glenn Morris CC: Stefan Monnier , 4543@debbugs.gnu.org Subject: Re: bug#4543: window-full-height-p References: <4ABB19F5.50908@gmx.at> <4AC5BC45.4060406@gmx.at> <4AC62293.6010403@gmx.at> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.77 > "Return non-nil if WINDOW is not the result of a vertical split. > WINDOW defaults to the selected window. (This function is not > appropriate for minibuffers.)" This looks good. Please install it. Thanks, martin From rgm@gnu.org Sat Oct 3 17:45:55 2009 Received: (at control) by emacsbugs.donarmstrong.com; 4 Oct 2009 00:45:55 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-4.5 required=4.0 tests=AWL,ONEWORD,X_DEBBUGS_NO_ACK autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from fencepost.gnu.org (fencepost.gnu.org [140.186.70.10]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n940jrPh001662 for ; Sat, 3 Oct 2009 17:45:54 -0700 Received: from rgm by fencepost.gnu.org with local (Exim 4.67) (envelope-from ) id 1MuFEX-0001aC-15; Sat, 03 Oct 2009 20:45:53 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19143.61504.975507.805426@fencepost.gnu.org> Date: Sat, 3 Oct 2009 20:45:52 -0400 From: Glenn Morris To: control Subject: control X-Debbugs-No-Ack: yes close 4543 From unknown Sun Aug 10 10:02:38 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Sun, 01 Nov 2009 15:24:24 +0000 User-Agent: Fakemail v42.6.9 # A New Hope # A long time ago, in a galaxy far, far away # something happened. # # Magically this resulted in the following # action being taken, but this fake control # message doesn't tell you why it happened # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator