From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Stephen J. Turnbull" Newsgroups: gmane.emacs.devel Subject: Re: Subwindow terminology Date: Mon, 07 Nov 2011 08:17:59 +0900 Message-ID: <874nygon6g.fsf@uwakimon.sk.tsukuba.ac.jp> References: <87wrbfrxqz.fsf@gnu.org> <4EB51CCC.6040806@gmx.at> <87hb2iohql.fsf@uwakimon.sk.tsukuba.ac.jp> <4EB53A16.3030604@gmx.at> <4EB64A64.8080902@gmx.at> <878vntob44.fsf@uwakimon.sk.tsukuba.ac.jp> <4EB6689F.1000202@gmx.at> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 X-Trace: dough.gmane.org 1320621498 31233 80.91.229.12 (6 Nov 2011 23:18:18 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sun, 6 Nov 2011 23:18:18 +0000 (UTC) Cc: dave@boostpro.com, martin rudalics , emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Nov 07 00:18:14 2011 Return-path: Envelope-to: ged-emacs-devel@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 1RNByf-00045S-L7 for ged-emacs-devel@m.gmane.org; Mon, 07 Nov 2011 00:18:14 +0100 Original-Received: from localhost ([::1]:43138 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RNByf-0001vx-2K for ged-emacs-devel@m.gmane.org; Sun, 06 Nov 2011 18:18:13 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:39355) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RNByd-0001vs-0e for emacs-devel@gnu.org; Sun, 06 Nov 2011 18:18:11 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RNByb-0000JZ-St for emacs-devel@gnu.org; Sun, 06 Nov 2011 18:18:10 -0500 Original-Received: from mgmt1.sk.tsukuba.ac.jp ([130.158.97.223]:51213) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RNByZ-0000Iz-SX; Sun, 06 Nov 2011 18:18:08 -0500 Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mgmt1.sk.tsukuba.ac.jp (Postfix) with ESMTP id 18C843FA06F0; Mon, 7 Nov 2011 08:18:00 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 107F41A274E; Mon, 7 Nov 2011 08:18:00 +0900 (JST) In-Reply-To: X-Mailer: VM 8.2.0a1 under 21.5 (beta31) "ginger" 2dbefd79b3d3 XEmacs Lucid (x86_64-unknown-linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 130.158.97.223 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 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-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:145915 Archived-At: Eli Zaretskii writes: > In order to make this discussion more productive, and avoid requesting > Martin to repeat things he already wrote, I suggest that people read > the discussions in bugs #9875 and #9873, and take it from there. No, I'll just deal with the fallout when XEmacs needs to sync to this ill-conceived mess. Martin doesn't write anything about why history of a window tree matters to Lisp programmers, but instead writes many things like But since I apparently failed to convey the semantics of this variable in the Elisp manual, someone else will have to take care of writing such a description. and > Why do you need to talk about subwindows at all? Because I didn't give this a thought yet ;-) If he needs to repeat those statements at this point, y'all are up to your necks in the Big Muddy. And reading *all* of both bugs doesn't explain why history of a window tree matters, except to Martin personally because he's the one who has to make sure invariants are maintained across operations on window trees. But the rest of us *using* the API are counting on him to get those invariants right. My suggestion for conformance to traditional nomenclature for windows and established nomenclature for trees (terms being defined are *emphasized*): (1) A *window* is a rectangular area entirely included in a frame in which a buffer can be displayed. (2) Windows are *live* when they are leaf nodes in a "live" frame. Otherwise they are *dead*. The behavior of dead windows is of interest only to implementors (with the single exception of windows resurrected by configuration restoration). (3) Windows are organized into window groups. Each *window group* is a one-dimensional contiguous array of conformable windows or window groups. *Conformable* means that they all have the same dimension in the direction perpendicular to the array, and that where the sides touch, the corners coincide. (I'm not wedded to the word "conformable".) Note that this means that every window group covers a rectangle. Window groups are referred to as "window rows" or "window columns" (*not* "horizontal" or "vertical") when the direction of the array is important. I'm not wedded to the term "window group", but it seems like it would make sense to Lisp programmers who neither need nor want to know about how window configurations are implemented. "Window node" might do if emphasizing the tree nature of window configurations seems like a good idea, with a "window" being a special kind of "window node" that can display a buffer. I don't know if the new implementation of window configurations requires that groups be maximal, ie, prohibits +---+---+---+---+ | 1 | 1 | 2 | 2 | +---+---+---+---+ where "1" and "2" label window group membership. Whether it does or not should be mentioned. (4) Each window group is therefore the root of a *window tree*. (Technically, a "window group tree", but that's a bit heavy, and I agree with Eli that giving people the right idea is more important than full precision in description.) (5) A *window configuration* is a window tree that fills the whole frame. (6) The words *root*, *leaf*, *sibling*, *child*, *parent*, *ancestor*, and *descendant* take their usual meanings in discussion of trees. Window APIs have a WINDOW argument. Unfortunately, this means that where appropriate, older APIs that now operate on window groups as well as windows need the sentence: >From Emacs 24, WINDOW may be a live window or window group. or similar in their docstrings. The Lispref can establish a convention to avoid such repetition. Any place you feel a *need* to use the term "subwindow" needs more thought about what you're actually doing. :-) (Of course I have an ulterior motive here, in that XEmacs uses the term "subwindow" for a completely different kind of object, a "native widget", but I think that sentence is nevertheless true.)