From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.devel Subject: Re: Window tree and window's internal height Date: Sat, 17 Nov 2018 19:39:36 +0100 Message-ID: <5BF06068.60103@gmx.at> References: <83o9anuahg.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1542479978 21712 195.159.176.226 (17 Nov 2018 18:39:38 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 17 Nov 2018 18:39:38 +0000 (UTC) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Nov 17 19:39:33 2018 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gO5VF-0005Yh-FD for ged-emacs-devel@m.gmane.org; Sat, 17 Nov 2018 19:39:33 +0100 Original-Received: from localhost ([::1]:50150 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gO5XL-0003X9-TB for ged-emacs-devel@m.gmane.org; Sat, 17 Nov 2018 13:41:43 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:44253) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gO5Va-00025Y-8w for emacs-devel@gnu.org; Sat, 17 Nov 2018 13:39:55 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gO5VZ-0002u4-EM for emacs-devel@gnu.org; Sat, 17 Nov 2018 13:39:54 -0500 Original-Received: from mout.gmx.net ([212.227.17.21]:42793) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gO5VR-0002fT-HN; Sat, 17 Nov 2018 13:39:45 -0500 Original-Received: from [192.168.1.101] ([212.95.7.234]) by mail.gmx.com (mrgmx103 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MN1Gu-1gLuiH3tQ8-006jMG; Sat, 17 Nov 2018 19:39:38 +0100 In-Reply-To: <83o9anuahg.fsf@gnu.org> X-Provags-ID: V03:K1:QXFH4d3SHUxB7XuSREejfuh/yU/gzJs0gTrIeTPnEG1eVFDqhha 813S8rdmExkhvYvjHIQIH4gG9UoQRvmjWpsZmA6akOpHkyLUw7G/gN5nGlosUIF75o8QXhp Ju6oXERSNIugx3HSXOxWm0Drgv7fSQP5MHIE+n4LpoJ0lb73Pq0523HjnctRRT3LnGfpKhB lgHzDbycx5d53Aof9eALg== X-UI-Out-Filterresults: notjunk:1;V01:K0:YUiAoao4Mho=:3NwAslgPkUYXsh6S58pbLs H+uaM7eg2kD1Uu1WuB8UKAp0yrCsI6hBoQoPuK4Vvr77S2Pn+GjVZbSL8zmNFASD9Uo/OlZCD 2N2UvoGpebebIrMQjNAeKrKxkUBegP3QrI2kZtr53LDriPbj6IW4cUT9HxxcJObr1qZpTZ4H0 uRvd90yEG1QGo7KNxjErkMED7Pq4EH+UECJ5yU9m8KQHoueXYQYLcvGzHeaugnXtIZkWeqEII ghq2o05EcitUsXr1rBocj2AhixjUVu5QwTjWX3d3n5HBvShsuwo+ewbR043m6pmTI/Iy7cnJB P3rufWdiIIgReFCF/lD0vAkGC0osyo0LS/Xj+wmekeCZepf5NiktY8eSZVfi1PqApUqKWPYwa n75S+bPouhH8tjyGOO7GHr7JXThe+AY7wRhbFjxBk2OeKfqCV0k+aW2b0dk+svUk7XINaW4Zk uPMTCPv3EfOcSJXsDmvMKw7J3rnzfa1eMrGWcGu4udsf+Li7ko5GnxKAsSqI96aP8yWbCGNzz S18XOFoig31vX5gwUgAxQZZfzEvoUMXLTJRVf40JqKRL++umEMObl/NEPo2v+rZErD71Mm5lD x5ubY4y/9T3YjinzNrfq93I5BCjzIPcMWgAcwIZQTrQ47HeJ6ZNZPYNGNQV+EbDjoIfsI1uqB xGQtcKsvopCs90Huw6I2k4Bo9017AuaGHkCn2fVINZMu3TTH7EsVkVfluBMc+DLpwAJWNyIip Nkn8UYXLLag/E3VzOu0b197foh/81koK9qJqZuEh77Qxs0n48Srm7/VYZYJZEsX0jH2y260g X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 212.227.17.21 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:231217 Archived-At: > First, we have this in the ELisp manual: > > A minibuffer window (*note Minibuffer Windows::) is not part of = its > frame=E2=80=99s window tree unless the frame is a minibuffer-only f= rame. > Nonetheless, most of the functions in this section accept the minib= uffer > window as an argument. Also, the function =E2=80=98window-tree=E2=80= =99 described at > the end of this section lists the minibuffer window alongside the a= ctual > window tree. > > The first sentence is incorrect, isn't it? Because Emacs disagrees: > > emacs -Q > M-: (window-next-sibling) RET > =3D> # > > And if that sentence is incorrect, we don't need the next two > "exceptions", right? Right, graph theoretically. For a long time, however, the Elisp manual has used the term "root", for example, in Emacs 22 as follows The return value is a list of the form `(ROOT MINI)', where ROOT represents the window tree of the frame's root window, and MINI is the frame's minibuffer window. which implies that Emacs' window tree is not free but a "rooted tree" and in a rooted tree every node except the root must have a unique parent node. But the minibuffer window does not have a parent so we would have two nodes without parent. Which means that our window tree concept per se is valid but using 'window-next-sibling' to get the minibuffer window from the root window is an incorrect naming convention. It's simply there because 'window-next-sibling' is a 1-to-1 reflection of the w->next field of the window structure in window.h. > Next, please have a look at the function window_internal_height: > > /* Return number of lines of text (not counting mode lines) in W. = */ > > int > window_internal_height (struct window *w) > { > int ht =3D w->total_lines; > > if (!MINI_WINDOW_P (w)) > { > if (!NILP (w->parent) > || WINDOWP (w->contents) > || !NILP (w->next) > || !NILP (w->prev) > || window_wants_mode_line (w)) > --ht; > > if (window_wants_header_line (w)) > --ht; > } > > return ht; > } > > I don't understand any of the conditions except window_wants_mode_line= > when we decide whether to decrease the height due to the mode line. > What do the other conditions have to do with the window's height? I > could perhaps understand the "WINDOWP (w->contents)" part, as some > kind of optimization for non-leaf windows, which assumes the default > of having the mode line, but the rest seem simply wrong, don't they? > (The WINDOWP condition is not really interesting, as I don't see any > call of this function for a non-leaf window.) Whatever these three conditions were meant for is beyond my imagination. window_internal_height was always off-limit for me. I wonder how these miscalculations would affect window_scroll_line_based (I hardly ever use modeline-less windows) though. > This is the immediate cause of bug#33363, which I could fix either by > a local change in try_window_id, or by modifying > window_internal_height to leave only the window_wants_mode_line > condition there. If the latter might be unsafe, maybe I should do the= > former on the release branch and the latter on master. WDYT? I would call window_body_height on the release branch and on master. And I would use window_body_height in window_scroll_line_based too. It should then take care of dividers and horizontal scroll bars on GUI windows as well. martin