From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: grischka Newsgroups: gmane.emacs.devel Subject: Re: Window configurations Date: Thu, 13 May 2010 13:40:29 +0200 Message-ID: <4BEBE52D.5080102@gmx.de> References: 4BE900E7.3090402@gmx.at <4BE96186.7060504@gmx.de> <4BEA74B7.2070609@gmx.at> <4BEA8D2D.4090109@gmx.de> <4BEAA73F.4060608@gmx.at> <4BEAF487.1070605@gmx.de> <4BEBD2E3.8020200@gmx.at> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1273751702 26645 80.91.229.12 (13 May 2010 11:55:02 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 13 May 2010 11:55:02 +0000 (UTC) Cc: emacs-devel@gnu.org To: martin rudalics Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu May 13 13:55:01 2010 connect(): No such file or directory 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.69) (envelope-from ) id 1OCX0E-0001YN-8C for ged-emacs-devel@m.gmane.org; Thu, 13 May 2010 13:54:58 +0200 Original-Received: from localhost ([127.0.0.1]:39888 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OCX0D-0003hC-7M for ged-emacs-devel@m.gmane.org; Thu, 13 May 2010 07:54:57 -0400 Original-Received: from [140.186.70.92] (port=59023 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OCWmN-0003zi-Hb for emacs-devel@gnu.org; Thu, 13 May 2010 07:40:40 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OCWmM-0004s9-Ef for emacs-devel@gnu.org; Thu, 13 May 2010 07:40:39 -0400 Original-Received: from mail.gmx.net ([213.165.64.20]:60387) by eggs.gnu.org with smtp (Exim 4.69) (envelope-from ) id 1OCWmM-0004rz-17 for emacs-devel@gnu.org; Thu, 13 May 2010 07:40:38 -0400 Original-Received: (qmail invoked by alias); 13 May 2010 11:40:35 -0000 Original-Received: from 184.121.113.82.net.de.o2.com (EHLO [10.54.16.196]) [82.113.121.184] by mail.gmx.net (mp024) with SMTP; 13 May 2010 13:40:35 +0200 X-Authenticated: #18588216 X-Provags-ID: V01U2FsdGVkX18FD4877qgF+5YRNxG4prC57dOKWuuECJOf9I5nMD BfCi7Qb9IzoI7B User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) In-Reply-To: <4BEBD2E3.8020200@gmx.at> X-Y-GMX-Trusted: 0 X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. 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:124739 Archived-At: martin rudalics wrote: > > In my book configuration is rules and state is result from their application > > (together with other conditions). Conflating the both will just produce a > > classical chicken & egg problem. > > If you specify a configuration procedurally you have to supply (1) an > initial state and (2) a set of actions and the order in which these > actions are applied. In the context of window configurations, the state > resulting after applying (2) to (1) is the "state of all windows" as I > call it. Hence the difference is basically only a matter of taste, > theroretically. It might be a matter of taste whether you prefer eggs or chicken but the difference is certainly more than theoretical ;) > From a practical point of view things are different: If you want to > derive (1) and (2) from the state of Emacs at some arbitrary point of > time you do have to guess a _minimum_ set of actions/rules that > reproduce the state of windows. Otherwise, you end up like the > designers of ECB who record _all_ actions applied by the user and > "replay" them to produce the desired state. I remember that differently. With ECB you can really choose from layouts visually and even create new ones with a sort of interactive layout editor. It is true that it stored the layouts as procedural sequences internally, but that is just an implementation detail. Aside from that it is really trivial to specify any reasonably complex layouts as simple lisp structure, with sizes in percent, similar to say framesets in html: (setq my-layout '( (div-v (30 div-h (75 top-window-1) (25 top-window-2) ) (55 div-h (25 div-v (50 sidebar-1) (25 sidebar-2) (25 sidebar-3) ) (75 edit-area) ) (15 tool-window) ))) That simple thing would be a pretty detailed layout already suited for almost all purposes (except GUD perhaps). More precisely, a layout _configuration_, which means that the elements (windows) are shown only when needed. Now you'd have a function that processes the tree to remove the unshown components, resizes the remaining components proportionally and then put it on screen in one go using good old split-window and then shows the buffers on top of each window's buffer stack. For that of course you need a second set of preferences, that is what buffer show in what pane: For example, *messages*, *compilation*, *completion*, etc. can be assigned to "tool-window", *speedbar* to sidebar-1, *help* on "top-1", files and such to "edit-area", and so on ... --- grischka