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 11:28:23 +0200 Message-ID: <4BEA74B7.2070609@gmx.at> References: 4BE900E7.3090402@gmx.at <4BE96186.7060504@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 1273656539 3188 80.91.229.12 (12 May 2010 09:28:59 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 12 May 2010 09:28:59 +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 11:28:57 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 1OC8FK-0005SE-Dy for ged-emacs-devel@m.gmane.org; Wed, 12 May 2010 11:28:54 +0200 Original-Received: from localhost ([127.0.0.1]:53161 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OC8FJ-0005x3-MG for ged-emacs-devel@m.gmane.org; Wed, 12 May 2010 05:28:53 -0400 Original-Received: from [140.186.70.92] (port=54329 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OC8F6-0005va-KY for emacs-devel@gnu.org; Wed, 12 May 2010 05:28:42 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OC8Ew-0003K3-TT for emacs-devel@gnu.org; Wed, 12 May 2010 05:28:40 -0400 Original-Received: from mail.gmx.net ([213.165.64.20]:60071) by eggs.gnu.org with smtp (Exim 4.69) (envelope-from ) id 1OC8Et-0003Iz-Vq for emacs-devel@gnu.org; Wed, 12 May 2010 05:28:30 -0400 Original-Received: (qmail invoked by alias); 12 May 2010 09:28:24 -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 (mp035) with SMTP; 12 May 2010 11:28:24 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX19XszYL981Xf9lWodqL35ksOKXdEnfUoeGoz8wKbf lXCpVdA+5QMD7R User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) In-Reply-To: <4BE96186.7060504@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:124719 Archived-At: > Maybe a matter of taste but I would not count on more conclusive behavior > from even more new options that allow packages to do what you want in case > anyone bothers to understand the complex specifications. Instead it might > be much more effective to implement conclusive behavior in a simple > algorithm > and remove any options for packages to circumvent it. I didn't describe a new option. The parameter I described is implicitly present in the current behavior of help windows. What I did was moving it from such windows to `display-buffer' and also to a function intended to get rid of window contents in some way. > For instance, one could have a buffer stack for each window, such that each > buffer displayed is added on top of the window's buffer stack. Probably a buffer should be added at the time it's unshown and still alive - yet another complication for `kill-buffer'. > If a > buffer is > killed or hidden, then the window's next buffer is displayed. That's more or less what I do now - modulo the stack behavior, but this could be changed. One complication is that window configurations would have to store the buffer stack and all buffer references. What's more problematic, however, is that it's not clear whether each and every occurrence of `set-window-buffer' should add its buffer to the stack. Currently, I put a buffer there only when `display-buffer' displays it. 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. > If there is > no "next", then the window is deleted (including the frame if it's the last > window). I agree. That is, I would certainly delete such a window if it never displayed another buffer since it was created. Also I would never iconify a frame. I'm not 100% sure whether a window should be deleted because all buffers it displayed have been killed in the meantime. 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. martin