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#9875: 24.0.90; Confusing description of the "window tree" in ELisp manual Date: Thu, 27 Oct 2011 03:27:40 -0400 Message-ID: References: <83zkgnbo50.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: dough.gmane.org 1319700503 21548 80.91.229.12 (27 Oct 2011 07:28:23 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 27 Oct 2011 07:28:23 +0000 (UTC) Cc: 9875@debbugs.gnu.org To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Oct 27 09:28:19 2011 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1RJKNv-0004KM-II for geb-bug-gnu-emacs@m.gmane.org; Thu, 27 Oct 2011 09:28:19 +0200 Original-Received: from localhost ([::1]:54038 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RJKNv-0006DA-26 for geb-bug-gnu-emacs@m.gmane.org; Thu, 27 Oct 2011 03:28:19 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:47999) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RJKNs-0006D5-Sm for bug-gnu-emacs@gnu.org; Thu, 27 Oct 2011 03:28:17 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RJKNr-00005Y-Ou for bug-gnu-emacs@gnu.org; Thu, 27 Oct 2011 03:28:16 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:38471) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RJKNr-00005U-J5 for bug-gnu-emacs@gnu.org; Thu, 27 Oct 2011 03:28:15 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.69) (envelope-from ) id 1RJKPa-0007N3-76 for bug-gnu-emacs@gnu.org; Thu, 27 Oct 2011 03:30:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 27 Oct 2011 07:30:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 9875 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 9875-submit@debbugs.gnu.org id=B9875.131970057128267 (code B ref 9875); Thu, 27 Oct 2011 07:30:02 +0000 Original-Received: (at 9875) by debbugs.gnu.org; 27 Oct 2011 07:29:31 +0000 Original-Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RJKP5-0007Lr-2V for submit@debbugs.gnu.org; Thu, 27 Oct 2011 03:29:31 -0400 Original-Received: from fencepost.gnu.org ([140.186.70.10] ident=Debian-exim) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RJKP1-0007Lj-Hz for 9875@debbugs.gnu.org; Thu, 27 Oct 2011 03:29:28 -0400 Original-Received: from eliz by fencepost.gnu.org with local (Exim 4.71) (envelope-from ) id 1RJKNI-0005C0-47; Thu, 27 Oct 2011 03:27:40 -0400 In-reply-to: (message from Stefan Monnier on Wed, 26 Oct 2011 18:21:01 -0400) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list Resent-Date: Thu, 27 Oct 2011 03:30:02 -0400 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) 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:53192 Archived-At: > From: Stefan Monnier > Cc: 9875@debbugs.gnu.org > Date: Wed, 26 Oct 2011 18:21:01 -0400 > > >> I think the first step is to choose a single name for those, and then > >> use it systematically. I think we should simply call "window" the > >> traditional "real" "live" "leaf" windows that display a buffer. As for > >> the other ones, we could go for "internal window", but I think "parent > >> window" is better, tho maybe someone has a better idea ("compound > >> window", "super window", ... ?) > > > How about "window tree node" or just "node"? > > Just "node" is much too vague for my taste. I meant to use "node" only when "window tree node" was mentioned in close proximity. For example: -- User Option: window-nest If this variable is `nil', `split-window' creates a new node in the window tree if and only if the old window had no parent node or shall be split orthogonally to the combination it is part of. If this variable is non-`nil', `split-window' always creates a new node that becomes the parent node of the new window. If this variable is always non-`nil', a frame's window tree is a binary tree so every node in the tree but the frame's window tree root has exactly one sibling node. Compare this with what's currently in the manual: -- User Option: window-nest If this variable is `nil', `split-window' creates a new parent window if and only if the old window has no parent window or shall be split orthogonally to the combination it is part of. If this variable is non-`nil', `split-window' always creates a new parent window. If this variable is always non-`nil', a frame's window tree is a binary tree so every window but the frame's root window has exactly one sibling. > "Window tree node" is a bit better but doesn't make it clear it's > not a leaf and is a window object. We will make that clear in the section where we describe the window tree. Once explained, it doesn't need to be mentioned again, if we abstain as much as possible from mentioning the nodes of the tree in other sections. > For that reason I prefer "window parent". That sounds mysterious, since it remains unclear what kind of thing is this "parent". "Parent node of the window" or "window's parent node" is better. > > That's what they are, right? > > They aren't just "node" (i.e. some intermediate element pointing to > others), they have most properties of windows, such as sizes and > positions (tho they don't display any buffer). That's true, but this fact is an implementation detail; we could easily have the nodes be different Lisp objects. E.g., some of the attributes without which a live window is unthinkable are nil in these "windows". And it doesn't help that we don't say anywhere which window attributes are non-trivially relevant to these "internal windows". So I think speaking about "nodes" instead will avoid confusion, because otherwise whenever we talk about a "window", the reader will always be in doubt whether this applies only to the "real", i.e. leaf windows, or to the "internal" ones as well.