From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Chong Yidong Newsgroups: gmane.emacs.devel Subject: Re: window groups Date: Thu, 29 May 2008 12:10:04 -0400 Message-ID: <87wsldgkgz.fsf@stupidchicken.com> References: <483D4E9A.9020001@gmx.at> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1212077698 7756 80.91.229.12 (29 May 2008 16:14:58 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 29 May 2008 16:14:58 +0000 (UTC) Cc: emacs-devel To: martin rudalics Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu May 29 18:15:38 2008 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1K1kmv-0003d6-Rt for ged-emacs-devel@m.gmane.org; Thu, 29 May 2008 18:15:38 +0200 Original-Received: from localhost ([127.0.0.1]:38668 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1K1km9-0002l4-Lv for ged-emacs-devel@m.gmane.org; Thu, 29 May 2008 12:14:49 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1K1kle-0002iV-0M for emacs-devel@gnu.org; Thu, 29 May 2008 12:14:18 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1K1klc-0002he-8W for emacs-devel@gnu.org; Thu, 29 May 2008 12:14:17 -0400 Original-Received: from [199.232.76.173] (port=46984 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1K1klb-0002hZ-VS for emacs-devel@gnu.org; Thu, 29 May 2008 12:14:16 -0400 Original-Received: from cyd.mit.edu ([18.115.2.24]:60961) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1K1klb-0002Xy-Uw for emacs-devel@gnu.org; Thu, 29 May 2008 12:14:16 -0400 Original-Received: by cyd.mit.edu (Postfix, from userid 1000) id A520D4E3B1; Thu, 29 May 2008 12:10:04 -0400 (EDT) In-Reply-To: <483D4E9A.9020001@gmx.at> (martin rudalics's message of "Wed, 28 May 2008 14:22:50 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux) X-detected-kernel: by monty-python.gnu.org: Linux 2.6 (newer, 2) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:97984 Archived-At: martin rudalics writes: > Conceptually, (2) should be sufficient to satisfy the requirements of > most IDE layouts like those of ECB or Eclipse "perspectives". > > - IDEs would typically specify one window group ("edit-area" in ECB, > "editor" in Eclipse) for each frame. Splitting any window of that > group would be done by setting the GROUP argument for `split-window' > to t. Other applications would not interfere with the layout of that > group since, by default, their GROUP argument would not be t. > > - IDE windows around that group (Eclipse "views") would be created as > follows: For the first such window either (i) call `split-window' with > GROUP set to `root' to obtain a full-height|width view, or (ii) call > `split-window' with GROUP set to nil to obtain a window just as > high|wide as the window group. Further windows would be created by > splitting an existing window with GROUP set to nil (or t for the more > complex layout-outlines of ECB ). > > Approach (i) appears best for displaying views on the left or right of > the edit area (file or tag views like the speedbar). Approach (ii) > might be given preference for displaying windows above or below the > edit area (compile, shell, or grep views). It seems to me that, in practice, any Elisp application that needs to control the window configuration will probably want to control over the entire frame. Otherwise, the resulting windows will likely be too small. WDYT? If so, maybe all that needs to be done, infrastructure wise, is a few functions for, e.g., creating window configurations from scratch, rather than window groups. I also think that the main problem here is the *user interface* to allow the user to choose one of several window configurations, akin to the "perspectives browser". Have you thought about how that might be implemented?