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#14825: 24.3.50; split-window-below miscounts window lines Date: Fri, 12 Jul 2013 12:09:45 +0300 Message-ID: <83ehb45eli.fsf@gnu.org> References: <83hag5vszy.fsf@gnu.org> <51DBD33D.4000307@gmx.at> <83bo6bww40.fsf@gnu.org> <51DD0B31.8000901@gmx.at> <83obaav2ug.fsf@gnu.org> <51DE504E.2010804@gmx.at> <834nc1uji4.fsf@gnu.org> <51DFBC95.5040207@gmx.at> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1373620269 17461 80.91.229.3 (12 Jul 2013 09:11:09 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 12 Jul 2013 09:11:09 +0000 (UTC) Cc: 14825@debbugs.gnu.org To: martin rudalics Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Jul 12 11:11:10 2013 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1UxZNd-0004Ft-5l for geb-bug-gnu-emacs@m.gmane.org; Fri, 12 Jul 2013 11:11:09 +0200 Original-Received: from localhost ([::1]:35226 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UxZNc-00047E-Nr for geb-bug-gnu-emacs@m.gmane.org; Fri, 12 Jul 2013 05:11:08 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:48792) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UxZNY-000474-7F for bug-gnu-emacs@gnu.org; Fri, 12 Jul 2013 05:11:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UxZNW-0006pL-Dl for bug-gnu-emacs@gnu.org; Fri, 12 Jul 2013 05:11:04 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:55303) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UxZNW-0006pH-AY for bug-gnu-emacs@gnu.org; Fri, 12 Jul 2013 05:11:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1UxZNW-0006KH-1q for bug-gnu-emacs@gnu.org; Fri, 12 Jul 2013 05:11:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 12 Jul 2013 09:11:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 14825 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 14825-submit@debbugs.gnu.org id=B14825.137362021724172 (code B ref 14825); Fri, 12 Jul 2013 09:11:02 +0000 Original-Received: (at 14825) by debbugs.gnu.org; 12 Jul 2013 09:10:17 +0000 Original-Received: from localhost ([127.0.0.1]:49617 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1UxZMm-0006Hf-16 for submit@debbugs.gnu.org; Fri, 12 Jul 2013 05:10:16 -0400 Original-Received: from mtaout20.012.net.il ([80.179.55.166]:50926) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1UxZMj-0006Gy-5N for 14825@debbugs.gnu.org; Fri, 12 Jul 2013 05:10:14 -0400 Original-Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0MPT00H00FZVSM00@a-mtaout20.012.net.il> for 14825@debbugs.gnu.org; Fri, 12 Jul 2013 12:09:51 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MPT00H7MG4EVA00@a-mtaout20.012.net.il>; Fri, 12 Jul 2013 12:09:51 +0300 (IDT) In-reply-to: <51DFBC95.5040207@gmx.at> X-012-Sender: halo1@inter.net.il X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:76272 Archived-At: > Date: Fri, 12 Jul 2013 10:21:41 +0200 > From: martin rudalics > CC: 14825@debbugs.gnu.org > > > These are externally visible, documented APIs; we cannot say they > > measure in line units, while in fact they measure in some other > > obscure units. And please note that someone who is not privy to the > > Emacs internals (on the C level) will not be able to get to the bottom > > of this once they bump into the problems this creates. The truth is > > buried deep behind macros and accessor functions whose names are as > > misleading as those of the APIs that expose them. > > > > This must be rectified. We can either fix the doc strings, or > > (better) introduce a separate set of APIs that counts lines in units > > of the default face. > > From the Elisp manual: > > Emacs provides several functions for finding the height and width of > a window. Except where noted, Emacs reports window heights and widths > as integer numbers of lines and columns, respectively. On a graphical > display, each "line" and "column" actually corresponds to the height > and width of a "default" character specified by the frame's default > font. Thus, if a window is displaying text with a different font or > size, the reported height and width for that window may differ from the > actual number of text lines or columns displayed within it. Yes, I know. But note that this extended explanation is also misleading, because it silently assumes that the default face was not remapped. If the default face _is_ remapped, then "the frame's default font" is ambiguous at best, since '(face-font 'default)' will return a font whose size is not the one meant by the above description. > If we want to put this explanation into the doc-strings, we'd probably > have to change the doc-strings of frame functions too. We could just have a warning there about not using these functions to count text lines in a window. > I still have to understand what you conisder a misconception here: IIUC > you say that if a buffer has a default face that differs from the > default face of the frame it is shown on, the height of any window > showing that buffer should be calculated in terms of that buffer's face. Yes, but it's not only about the default face. Did you try setting line-spacing to something non-nil lately? Try it: it's a lot of fun looking at what window-text-height and its ilk return in that case. > So when you show another buffer in that window, the window's height > might change nominally although it does not change visually. Right. > Now if the window is the only one on its frame, you would have to change > the frame's nominal height as well The number of lines in the frame does not necessarily need to change, because a frame has other elements, even if it has only one window -- the mode line, the menu bar, the tool bar, etc. What matters is the root window, not the frame. So we can still measure a frame in canonical units. > If OTOH the frame contains more than one window, we would have a > hard time to relate the height of these windows to that of the > frame. The only reliable way of doing that is in pixels anyway. > Lifting the present relationship without providing a viable alternative > would be a misconception IMO. That's why I suggested to introduce a separate set of APIs. > My apologies if what I say here doesn't fit your expectations. But > doing ad hoc changes to code that has evolved over decades is over my > head. I didn't suggest that. My suggestion pols down to this: . Say in the doc strings of all these functions that their return values should NOT be used to count lines or columns of text in a window; . Add a separate set of APIs for counting the number of default-face text lines and characters in a window.