From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Window tree and window's internal height Date: Sun, 18 Nov 2018 22:25:00 +0200 Message-ID: <834lcet9pf.fsf@gnu.org> References: <83o9anuahg.fsf@gnu.org> <5BF06068.60103@gmx.at> <83bm6mtm9l.fsf@gnu.org> <5BF1C03B.2030801@gmx.at> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: blaine.gmane.org 1542572609 26722 195.159.176.226 (18 Nov 2018 20:23:29 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 18 Nov 2018 20:23:29 +0000 (UTC) Cc: emacs-devel@gnu.org To: martin rudalics Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Nov 18 21:23:24 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 1gOTbH-0006q7-6t for ged-emacs-devel@m.gmane.org; Sun, 18 Nov 2018 21:23:23 +0100 Original-Received: from localhost ([::1]:53299 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gOTdN-0003aZ-ME for ged-emacs-devel@m.gmane.org; Sun, 18 Nov 2018 15:25:33 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34762) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gOTcp-0003aS-Gs for emacs-devel@gnu.org; Sun, 18 Nov 2018 15:25:00 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gOTcm-0001ek-DY for emacs-devel@gnu.org; Sun, 18 Nov 2018 15:24:59 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:33474) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gOTcm-0001eg-AJ; Sun, 18 Nov 2018 15:24:56 -0500 Original-Received: from [176.228.60.248] (port=2174 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1gOTcm-0007JO-2k; Sun, 18 Nov 2018 15:24:56 -0500 In-reply-to: <5BF1C03B.2030801@gmx.at> (message from martin rudalics on Sun, 18 Nov 2018 20:40:43 +0100) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e 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:231223 Archived-At: > Date: Sun, 18 Nov 2018 20:40:43 +0100 > From: martin rudalics > CC: emacs-devel@gnu.org > > >> > A minibuffer window (*note Minibuffer Windows::) is not part of its > >> > frame’s window tree unless the frame is a minibuffer-only frame. > >> > Nonetheless, most of the functions in this section accept the minibuffer > >> > window as an argument. Also, the function ‘window-tree’ described at > >> > the end of this section lists the minibuffer window alongside the actual > >> > window tree. > [...] > > So maybe we should simply say that the mini-window doesn't have a > > parent, instead of what we say now? > > We can do that. But that would not remove or explain the fact that > the minibuffer is the next sibling of the root window and the root > window the previous sibling of the minibuffer window. We could add a > sentence like "For convenience, the function `window-next-sibling', > when invoked with the root window as argument, returns its frame's > minibuffer window if the frame has a minibuffer window and is not a > minibuffer-only frame." unless it's even more confusing. 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. > > Looking at w->next _was_ what tripped me in the first place: I didn't > > expect a sole window on a TTY frame to have a non-nil object pointed > > by its 'next' pointer. > > 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? 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! > I don't like it much because when I want to display a "permanent" > minibuffer window at the top of the frame, it must be still the "next" > sibling of the root window. Worse even - I cannot easily display the > echo area at the top of the frame and the minibuffer at its bottom in > two (semi-)permanent windows. I guess you will need to invent one more "bastard" node in the tree that doesn't have a parent? > > window_scroll_line_based is never used on GUI frames, > > I wasn't aware of that. I always thought the comment > > /* If we must, use the pixel-based version which is much slower than > the line-based one but can handle varying line heights. */ > > means that we would allow for some sort of line based scrolling on GUI > frames. 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); > > and dividers and > > scroll bars always have exactly zero size on TTY frames. Right? > > Right. OK, thanks. I'll make the changes.