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#14825: 24.3.50; split-window-below miscounts window lines Date: Fri, 12 Jul 2013 10:21:41 +0200 Message-ID: <51DFBC95.5040207@gmx.at> 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> NNTP-Posting-Host: plane.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 1373617337 19570 80.91.229.3 (12 Jul 2013 08:22:17 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 12 Jul 2013 08:22:17 +0000 (UTC) Cc: 14825@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Jul 12 10:22:17 2013 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1UxYcF-0008QQ-Nv for geb-bug-gnu-emacs@m.gmane.org; Fri, 12 Jul 2013 10:22:11 +0200 Original-Received: from localhost ([::1]:51076 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UxYcF-0002Q7-AR for geb-bug-gnu-emacs@m.gmane.org; Fri, 12 Jul 2013 04:22:11 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:35631) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UxYc8-0002M6-Sk for bug-gnu-emacs@gnu.org; Fri, 12 Jul 2013 04:22:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UxYc7-0007Tg-Hu for bug-gnu-emacs@gnu.org; Fri, 12 Jul 2013 04:22:04 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:55175) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UxYc7-0007Tc-EA for bug-gnu-emacs@gnu.org; Fri, 12 Jul 2013 04:22:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1UxYc7-00046X-6E for bug-gnu-emacs@gnu.org; Fri, 12 Jul 2013 04:22:03 -0400 X-Loop: help-debbugs@gnu.org Resent-From: martin rudalics Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 12 Jul 2013 08:22:03 +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.137361731415737 (code B ref 14825); Fri, 12 Jul 2013 08:22:03 +0000 Original-Received: (at 14825) by debbugs.gnu.org; 12 Jul 2013 08:21:54 +0000 Original-Received: from localhost ([127.0.0.1]:49490 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1UxYbx-00045l-Qq for submit@debbugs.gnu.org; Fri, 12 Jul 2013 04:21:54 -0400 Original-Received: from mout.gmx.net ([212.227.15.18]:50272) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1UxYbw-00045U-8L for 14825@debbugs.gnu.org; Fri, 12 Jul 2013 04:21:52 -0400 Original-Received: from [62.47.40.146] ([62.47.40.146]) by mail.gmx.com (mrgmx103) with ESMTPA (Nemesis) id 0MWCKz-1UhtRI1AUL-00XM4O; Fri, 12 Jul 2013 10:21:45 +0200 In-Reply-To: <834nc1uji4.fsf@gnu.org> X-Provags-ID: V03:K0:23AHks2gP7tQ1WPVSE8tFpVwQHOnFiWmJvafu6JUgsq6ZlVmUQh rMa9OLJiDD8waYMIYLulJ8ZC74THaMAfH7POBufTGnHL6iMpR8FWQRkidw4S3LHg7WFSieT fPkPaFTTfndkfsPc/pKKhK3VdcuUJ83WiCAY9anGnnNljbQEMFUQF6sY0QkGLmVOBPpHLAL mCgcMshVySvh5huCVJndA== 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:76266 Archived-At: > I think we are miscommunicating. I didn't say that solving this bug > will make things easier for the core Emacs developers. I said that > currently we have an array of functions that lie through their teeth > about their contract. Here's a typical example: > > (window-text-height &optional WINDOW) > > Return the height in lines of the text display area of WINDOW. > WINDOW must be a live window and defaults to the selected one. > > The returned height does not include the mode line, any header line, > nor any partial-height lines at the bottom of the text area. > > 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. If we want to put this explanation into the doc-strings, we'd probably have to change the doc-strings of frame functions too. >> PS: It can be easily done as soon as we do resizing pixelwise. But it >> would break a few functions like `window-edges' in the sense that the >> lower edge of A would not be necessary equal to the upper edge of C. > > Functions like window-edges shouldn't rely on this in the first place. `window-edges' is a function available to users and as a user of that function I would expect it to behave in some expected sense. > In any case, it certainly makes no sense to bend public interfaces so > much, just because that makes things easier internally. As I tried to explain twice in this thread, internally I don't care at all about lines and columns and what they stand for. The sooner we lift the impact of faces (and their changes) on the size of windows or frames the better. > It just took > me the better part of this week to repair damage due to this > misconception to something as basic as scrolling. Isn't that reason > good enough to consider this a serious shortcoming? 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. So when you show another buffer in that window, the window's height might change nominally although it does not change visually. Now if the window is the only one on its frame, you would have to change the frame's nominal height as well, since otherwise we would get, for example, a window that's higher than its frame. 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. Lifting the present relationship without providing a viable alternative would be a misconception IMO. For me, changing to a default size of 1 as canonical unit is a viable alternative. 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. martin