From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.devel Subject: Re: Window configurations Date: Thu, 13 May 2010 12:22:27 +0200 Message-ID: <4BEBD2E3.8020200@gmx.at> 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> 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 1273750205 21579 80.91.229.12 (13 May 2010 11:30:05 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 13 May 2010 11:30:05 +0000 (UTC) Cc: emacs-devel@gnu.org To: grischka Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu May 13 13:30:04 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 1OCWc7-00058j-8M for ged-emacs-devel@m.gmane.org; Thu, 13 May 2010 13:30:04 +0200 Original-Received: from localhost ([127.0.0.1]:37441 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OCWc6-0004oX-D7 for ged-emacs-devel@m.gmane.org; Thu, 13 May 2010 07:30:02 -0400 Original-Received: from [140.186.70.92] (port=35992 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OCWTA-0007cI-70 for emacs-devel@gnu.org; Thu, 13 May 2010 07:20:55 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OCVYl-0006rP-VC for emacs-devel@gnu.org; Thu, 13 May 2010 06:22:33 -0400 Original-Received: from mail.gmx.net ([213.165.64.20]:40908) by eggs.gnu.org with smtp (Exim 4.69) (envelope-from ) id 1OCVYl-0006qa-K8 for emacs-devel@gnu.org; Thu, 13 May 2010 06:22:31 -0400 Original-Received: (qmail invoked by alias); 13 May 2010 10:22:28 -0000 Original-Received: from 62-47-53-1.adsl.highway.telekom.at (EHLO [62.47.53.1]) [62.47.53.1] by mail.gmx.net (mp007) with SMTP; 13 May 2010 12:22:28 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1/z6CJgE7PzfGYuQMUIbO7sTBrGpOzn7/gTLh0nsm QQnWqO8fbrP5zQ User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) In-Reply-To: <4BEAF487.1070605@gmx.de> 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:124737 Archived-At: >> I'm not sure whether I get your point. But windows are first class >> citizens in the Elisp world and `split-window' must be allowed to create >> arbitrarily complex window trees on an arbitrarily complex machine. > > Which does not mean that any feature can be allowed to use split-window > as it happens to think. Features shouldn't do so, indeed. `display-buffer' is the preferred interface. >> In my book a "window configuration" is "the state of all windows". > > 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. 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. > There is no need to guess intentions if users were allowed to express them > (and emacs was disallowed to ignore them). If we can come up with some simple set of customizable variables to express the users' intentions. But I'm afraid we won't be able to do that. Suppose I want to automatically show "another" buffer in some window. How is this other buffer chosen? From the list of buffers that (a) have been already displayed in that window, (b) that window's frame, (c) somewhere (d) are alive? >> The heuristics should guess the "intuitively right window" in a way >> which can be roughly measured by the number of postings criticizing its >> implementation. > > You want "display-buffer" query the emacs bug tracker? ;) More or less so, with some manual intervention ;-) martin