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: Wed, 12 May 2010 15:03:59 +0200 Message-ID: <4BEAA73F.4060608@gmx.at> References: 4BE900E7.3090402@gmx.at <4BE96186.7060504@gmx.de> <4BEA74B7.2070609@gmx.at> <4BEA8D2D.4090109@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 1273669618 18284 80.91.229.12 (12 May 2010 13:06:58 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 12 May 2010 13:06:58 +0000 (UTC) Cc: emacs-devel@gnu.org To: grischka Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed May 12 15:06:55 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 1OCBeF-000323-LA for ged-emacs-devel@m.gmane.org; Wed, 12 May 2010 15:06:51 +0200 Original-Received: from localhost ([127.0.0.1]:56680 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OCBbk-0001Jc-Aj for ged-emacs-devel@m.gmane.org; Wed, 12 May 2010 09:04:16 -0400 Original-Received: from [140.186.70.92] (port=47491 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OCBbe-0001JX-6M for emacs-devel@gnu.org; Wed, 12 May 2010 09:04:11 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OCBbX-0002LK-El for emacs-devel@gnu.org; Wed, 12 May 2010 09:04:09 -0400 Original-Received: from mail.gmx.net ([213.165.64.20]:42540) by eggs.gnu.org with smtp (Exim 4.69) (envelope-from ) id 1OCBbX-0002Ky-2k for emacs-devel@gnu.org; Wed, 12 May 2010 09:04:03 -0400 Original-Received: (qmail invoked by alias); 12 May 2010 13:04:01 -0000 Original-Received: from 62-47-41-249.adsl.highway.telekom.at (EHLO [62.47.41.249]) [62.47.41.249] by mail.gmx.net (mp048) with SMTP; 12 May 2010 15:04:01 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX199ZVNy1CR90Uv3OFXFbwvK7KrTaCvOHdfjNJHUDg vyCsrIWYigc625 User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) In-Reply-To: <4BEA8D2D.4090109@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:124722 Archived-At: >> ... 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. There's hardly anything to implement "on top" of this. The primitives are `set-window-buffer' and `kill-buffer' so any implementation on top of this would have to hook into `window-configuration-change-hook' and `kill-buffer-hook'. > 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, 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. > (and anyway the result of some such is not a "window-configuration" but at > most a "window-state"). In my book a "window configuration" is "the state of all windows". > 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. The question which buffer I want to display must be solved heuristically because it's too complex to analyze the intentions of each and every Emacs user (and possibly provide the necessary customizations) in Elisp. The heuristics should guess the "intuitively right window" in a way which can be roughly measured by the number of postings criticizing its implementation. > 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. IIUC that's what packages like ECB do. And ECB leaves it to Emacs and its users to modify the configuration/state of the edit area. > 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. martin