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: Mon, 19 Nov 2018 10:41:03 +0100 Message-ID: <5BF2852F.7010400@gmx.at> References: <83o9anuahg.fsf@gnu.org> <5BF06068.60103@gmx.at> <83bm6mtm9l.fsf@gnu.org> <5BF1C03B.2030801@gmx.at> <834lcet9pf.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: 7bit X-Trace: blaine.gmane.org 1542620397 29821 195.159.176.226 (19 Nov 2018 09:39:57 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 19 Nov 2018 09:39:57 +0000 (UTC) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Nov 19 10:39:53 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 1gOg24-0007c3-29 for ged-emacs-devel@m.gmane.org; Mon, 19 Nov 2018 10:39:52 +0100 Original-Received: from localhost ([::1]:54932 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gOg4A-0005Iy-ML for ged-emacs-devel@m.gmane.org; Mon, 19 Nov 2018 04:42:02 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:35981) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gOg3P-0005Ih-U3 for emacs-devel@gnu.org; Mon, 19 Nov 2018 04:41:16 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gOg3K-0005qS-17 for emacs-devel@gnu.org; Mon, 19 Nov 2018 04:41:15 -0500 Original-Received: from mout.gmx.net ([212.227.15.15]:39923) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gOg3J-0005pI-NY; Mon, 19 Nov 2018 04:41:09 -0500 Original-Received: from [192.168.1.101] ([46.125.249.53]) by mail.gmx.com (mrgmx003 [212.227.17.190]) with ESMTPSA (Nemesis) id 0MEnjW-1gDBqi3pV4-00G4tM; Mon, 19 Nov 2018 10:41:07 +0100 In-Reply-To: <834lcet9pf.fsf@gnu.org> X-Provags-ID: V03:K1:VG0ngnu2+cej17NYY3C+tZ9pIqzqvjolphUNvJBgOStjfnE0hHm gTg9anP/9ykM9kV7n1b/fEWoB8/msSiv3z+jz3QawFknkXyG9W/wpki/WYsx5LV1Jwi4wqG Ts1mzCozYaT3p5m0hUWXBLtijMQd84bpRvkllHE8tS+5bKIFv834WYMWAkMVyNTMBb4KU7R ZH7gPh4Ox8uay0swP8BAg== X-UI-Out-Filterresults: notjunk:1;V01:K0:fl0pJuWHrAQ=:1fH0iZ2NWER8nH1G6itBhi uLecNlaTzQU1E96JdL3Q0kaMgPBmDj7ZJ5iZ6vCTfBsJs+fk4LGQcdOU9wO9C36oWvCoIMX30 H+r9aFFa6jXa2+D6OIWuMSYJNKDsiVPINWvAVqzcGu7LJv7sU0DCA/eWL6Wz4kX9KADERKIpH ObWdCaDS/rf28BDrNG2VzzSQeLqZOcW6ROthj5VxdlObWgES7bNOuGy64BGDzLQnjh3U30KW1 i98aT3fNBxRbB2LctJk17f4sDr0UQfxqj4yhiMr2XEmv+VNY5Y00CsYRdJ2NGYkhQHB+lIXye eq76HosPg8fs6G8bBlD+UKTN8a3DRDybuBPjHsfiB+sA1q9NS+pcgyYPB8PRC2nXnDl0GgccR 2xnwHJcFidNebh99qfYpPA2zRbOOZHJTLCVYVj/n+jk2U8FfrmF7bkqX6ElwVphU3yAb62Qul qp8Etjqob5uOqh4EUo4w+NjxmxAqRLgTSejCBV9OKtu4Fe0YG6/0ycGr8NlfNlRxg/LASbOPe pHV7kH69XXK/+4z9I0l8nzcMQs49yc5UG/eFqkLVx1Yqz9YnUpFd3noA8tEgD895f18kGTfCR pCCffRwyQux5/AcM1QMswImudxeBgFt18UxXY/xLLDLj85539ee33YQKCpc75NC9omZNoxoN8 gEmaa2JdtiFo2iAJjR5sb+8a7FYcLMoJzgLoQ4Zx1lhjcmD89IrUNr9sWeE3zQmppP91KceFl UbdGzdIJky7d54yvvih6WXsKbQkyFekaEX4Ru1c9yIInOF6cVXtJfzqCVe9CKd2Lw59snpd8 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 212.227.15.15 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:231226 Archived-At: > I thought of saying something like > > The minibuffer window does not have a parent window, but it > nevertheless is a sibling of the frame's root window, and thus can > be reached via window-next-sibling. I'd start the sentence with "A minibuffer window that is not alone on its frame ..." but for the rest it's fine with me. >> I miss you here. The display code is the major client of this trick > > And you therefore assumed that I must remember this factoid by heart? Indeed, I did. Also because most of the Elisp windows code I added swirls away this factoid by using 'window-right' and 'window-left'. > I don't. I've read the description of the window tree, and thought > "this is a single window on its TTY frame, it cannot possibly have > anything non-nil pointed to by its 'next' pointer". Oops! So sometimes such details are important in the manual. Still, I wouldn't rely on the Elisp manual to tell me anything about the underlying C structures. Inherently, the root of each window tree is a virtual "inner frame" window which must have at least one and at most two child windows - the root window and the minibuffer window. This is important for resizing operations which have to guarantee that the heights of the minibuffer and root window sum up to the height of the inner frame. Since for the rest that virtual window has no importance - once set up its child windows can never change - code for it was never written out explicitly. So a correct specification of our window tree concept would have to talk about that inner frame window but then the entire definitions of root window would have to be rewritten ... > I guess you will need to invent one more "bastard" node in the tree > that doesn't have a parent? And make it the next sibling of the other minibuffer window. It gives up the idea of an "ordered" tree but since the root has a next sibling already it's not a rooted tree anyway. > No. The code is very unequivocal: > > /* If we must, use the pixel-based version which is much slower than > the line-based one but can handle varying line heights. */ > if (FRAME_WINDOW_P (XFRAME (XWINDOW (window)->frame))) <<<<<<<<<< > window_scroll_pixel_based (window, n, whole, noerror); > else > window_scroll_line_based (window, n, whole, noerror); The code is unequivocal, the comment leaves much room to interpretation. martin