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: Wed, 12 May 2010 13:12:45 +0200 Message-ID: <4BEA8D2D.4090109@gmx.de> References: 4BE900E7.3090402@gmx.at <4BE96186.7060504@gmx.de> <4BEA74B7.2070609@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 1273662785 25001 80.91.229.12 (12 May 2010 11:13:05 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 12 May 2010 11:13:05 +0000 (UTC) Cc: emacs-devel@gnu.org To: martin rudalics Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed May 12 13:13: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 1OC9s8-0000ct-4Y for ged-emacs-devel@m.gmane.org; Wed, 12 May 2010 13:13:04 +0200 Original-Received: from localhost ([127.0.0.1]:54868 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OC9s7-0002tu-DO for ged-emacs-devel@m.gmane.org; Wed, 12 May 2010 07:13:03 -0400 Original-Received: from [140.186.70.92] (port=52834 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OC9rx-0002tc-EY for emacs-devel@gnu.org; Wed, 12 May 2010 07:12:58 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OC9rw-0006zN-Al for emacs-devel@gnu.org; Wed, 12 May 2010 07:12:53 -0400 Original-Received: from mail.gmx.net ([213.165.64.20]:51914) by eggs.gnu.org with smtp (Exim 4.69) (envelope-from ) id 1OC9rv-0006z8-WD for emacs-devel@gnu.org; Wed, 12 May 2010 07:12:52 -0400 Original-Received: (qmail invoked by alias); 12 May 2010 11:12:50 -0000 Original-Received: from 184.121.113.82.net.de.o2.com (EHLO [10.54.24.68]) [82.113.121.184] by mail.gmx.net (mp019) with SMTP; 12 May 2010 13:12:50 +0200 X-Authenticated: #18588216 X-Provags-ID: V01U2FsdGVkX1/0kPYIObT0hDGAe8DgZyQub2vCuovnGl6G7dDq1H gWnIqQC3wIrSaZ User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) In-Reply-To: <4BEA74B7.2070609@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:124721 Archived-At: martin rudalics wrote: > ... And, obviously, stacks have the usual annoying attitude to > forget about their tops, so sooner or later someone will come up and ask > for a ring or eventually a buffer history tree for each window and some > way to navigate it. You're already lost if you plan to expose details of your design to users or packages. If people want rings or history, they can still implement it on top of your design as a whole. It is then their responsibility to make their feature conclusive to yours. > But all this doesn't easily solve the problem of displaying a buffer in > the intuitively right window, for example, the window where it has been > already shown a couple of times before. For this we could scan all > windows' stacks and pick the one that has this buffer at the most > prominent position - maybe supplied with some sort of a time-stamp. One mistake is to cater for windows on the same level of generality as you obviously do for low level lisp. Of course you want functions "cons" etc. to allow generation of arbitrarily complex lisp structures, but it cannot be the point of "split-window" to generate arbitrarily complex window-trees, (and anyway the result of some such is not a "window-configuration" but at most a "window-state"). The other mistake is _not_ to cater for windows on the same level of _reliability_ as you obviously do for low level lisp. "Cons" doesn't work "intuitively" in the sense of "heuristically", and one has to accept that there is no other "intuitively right window" to display some buffer except the exactly one defined location where the user wants to see it. And that is actually what "window-configuration" can only mean: A way to define windows for particular content (aka. buffers) _before_ the window exists physically. From then on it is easy, you just need to tell "display-buffer" to use that window rsp. to generate it if it doesn't yet exist. --- grischka > > martin >