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 07:15:44 +0900 Message-ID: <8762iwoq27.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 1320617765 9827 80.91.229.12 (6 Nov 2011 22:16:05 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sun, 6 Nov 2011 22:16:05 +0000 (UTC) Cc: Dave Abrahams , emacs-devel@gnu.org To: martin rudalics Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Nov 06 23:15:59 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 1RNB0R-0008NW-2h for ged-emacs-devel@m.gmane.org; Sun, 06 Nov 2011 23:15:59 +0100 Original-Received: from localhost ([::1]:34742 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RNB0Q-0002Ic-JJ for ged-emacs-devel@m.gmane.org; Sun, 06 Nov 2011 17:15:58 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:57687) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RNB0N-0002IK-RW for emacs-devel@gnu.org; Sun, 06 Nov 2011 17:15:56 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RNB0M-00010f-M6 for emacs-devel@gnu.org; Sun, 06 Nov 2011 17:15:55 -0500 Original-Received: from mgmt1.sk.tsukuba.ac.jp ([130.158.97.223]:36058) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RNB0M-0000zz-6B for emacs-devel@gnu.org; Sun, 06 Nov 2011 17:15:54 -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 6B1683FA0750; Mon, 7 Nov 2011 07:15:44 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 5E0521A274E; Mon, 7 Nov 2011 07:15:44 +0900 (JST) In-Reply-To: <4EB6689F.1000202@gmx.at> 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:145914 Archived-At: martin rudalics writes: > > Does anyone ever actually think in genealogical terms? [...] > > Does anybody *ever* care about anything except in which of the > > visible windows output will appear (and similar static questions > > about the current window configuration)? > > People interested in manipulating window configurations will have to > care. They never have cared about genealogy in the past. I don't see why they need to now; sure, you have the issue that window identity needs to be considered carefully in implementation since variables may refer to them. Of course they need to be implicitly aware of the tree structure, but that can be deduced from the arrangement of windows in most cases. The genealogical issues should be managed internally, and AFAICS they can be managed internally. > > And at the Lisp level, only leaf windows are actually accessible as > > far as I know. Are there any Lisp functions that operate on parent > > windows, other than those that create or destroy children? > > Plenty. You can split, delete, and resize them Not up to now. You could split a leaf window; this creates a sibling, and may involve either creation of a new parent or addition of the sibling as a child of the existing parent. The function API doesn't know about the parent though. Similarly, the Lisp API may delete all siblings of a given window, in which case the parent would be deleted and the child become a child of its grandparent. If you resize a leaf perpendicularly to relation to its siblings, the parent will be implicitly resized. Parents were simply a device for keeping the tree structure. Are you saying that parent windows are now visible to the Lisp API for operations like split, even though you can't select them for displaying buffers? This seems like a bad idea to me. > (you can't resize and delete a frame's root window, obviously). Except by resizing or deleting the frame.