From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.bugs Subject: bug#4543: window-full-height-p Date: Fri, 25 Sep 2009 17:04:10 +0200 Message-ID: <4ABCDBEA.8060502@gmx.at> References: <4ABB19F5.50908@gmx.at> <4ABC73DB.1060308@gmx.at> <83vdj7tlup.fsf@gnu.org> <4ABCBEC7.70901@gmx.at> <83my4jta8h.fsf@gnu.org> Reply-To: martin rudalics , 4543@emacsbugs.donarmstrong.com NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1253892461 6477 80.91.229.12 (25 Sep 2009 15:27:41 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 25 Sep 2009 15:27:41 +0000 (UTC) Cc: 4543@emacsbugs.donarmstrong.com To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Sep 25 17:27:34 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 1MrChZ-0005Ib-E1 for geb-bug-gnu-emacs@m.gmane.org; Fri, 25 Sep 2009 17:27:17 +0200 Original-Received: from localhost ([127.0.0.1]:53308 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MrChY-0005Zz-RD for geb-bug-gnu-emacs@m.gmane.org; Fri, 25 Sep 2009 11:27:16 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MrChU-0005ZY-Lp for bug-gnu-emacs@gnu.org; Fri, 25 Sep 2009 11:27:12 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MrChP-0005ZC-MJ for bug-gnu-emacs@gnu.org; Fri, 25 Sep 2009 11:27:11 -0400 Original-Received: from [199.232.76.173] (port=42247 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MrChP-0005Z9-Gu for bug-gnu-emacs@gnu.org; Fri, 25 Sep 2009 11:27:07 -0400 Original-Received: from rzlab.ucr.edu ([138.23.92.77]:50322) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MrChP-0003lg-3K for bug-gnu-emacs@gnu.org; Fri, 25 Sep 2009 11:27:07 -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 n8PFR4XT017357; Fri, 25 Sep 2009 08:27:05 -0700 Original-Received: (from debbugs@localhost) by rzlab.ucr.edu (8.14.3/8.14.3/Submit) id n8PFA5GC014185; Fri, 25 Sep 2009 08:10:05 -0700 Resent-Date: Fri, 25 Sep 2009 08:10:05 -0700 X-Loop: owner@emacsbugs.donarmstrong.com Resent-From: martin rudalics Resent-To: bug-submit-list@donarmstrong.com Resent-CC: Emacs Bugs 2Resent-Date: Fri, 25 Sep 2009 15:10:05 +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.125389105912424 (code B ref 4543); Fri, 25 Sep 2009 15:10:05 +0000 Original-Received: (at 4543) by emacsbugs.donarmstrong.com; 25 Sep 2009 15:04:19 +0000 X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. Original-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 Original-Received: (qmail invoked by alias); 25 Sep 2009 15:04:11 -0000 Original-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 User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) In-Reply-To: <83my4jta8h.fsf@gnu.org> X-Y-GMX-Trusted: 0 X-FuHaFi: 0.63 X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) Resent-Date: Fri, 25 Sep 2009 11:27:11 -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:31504 Archived-At: > 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