From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Window configurations Date: Tue, 01 Jun 2010 15:20:58 -0400 Message-ID: References: <4BB4CF6B.2000007@alice.it> <87zl0rtmqy.fsf@mail.jurta.org> <871vdu6qn5.fsf@mail.jurta.org> <87bpcv1wvt.fsf@mail.jurta.org> <4BE13828.2030609@gmx.at> <87vdb2qo82.fsf@mail.jurta.org> <4BE27C17.3030005@gmx.at> <87vdav4vx5.fsf@mail.jurta.org> <4BE900E7.3090402@gmx.at> <87r5liqv8f.fsf@mail.jurta.org> <4BEA74DC.2060103@gmx.at> <87y6fns8qo.fsf@mail.jurta.org> <4BECF4D6.9030707@gmx.at> <87632na2af.fsf@mail.jurta.org> <4C03F1B5.8040708@gmx.at> <4C04D1BF.9070902@gmx.at> <4C052F8C.8030208@gmx.at> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1275420448 1611 80.91.229.12 (1 Jun 2010 19:27:28 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 1 Jun 2010 19:27:28 +0000 (UTC) Cc: Juri Linkov , Emacs To: martin rudalics Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Jun 01 21:27:26 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 1OJX7U-00016t-65 for ged-emacs-devel@m.gmane.org; Tue, 01 Jun 2010 21:27:24 +0200 Original-Received: from localhost ([127.0.0.1]:42522 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OJX7T-0006mi-Ac for ged-emacs-devel@m.gmane.org; Tue, 01 Jun 2010 15:27:23 -0400 Original-Received: from [140.186.70.92] (port=34045 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OJX1M-0001hA-Mu for emacs-devel@gnu.org; Tue, 01 Jun 2010 15:21:09 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OJX1K-0005n3-Lb for emacs-devel@gnu.org; Tue, 01 Jun 2010 15:21:04 -0400 Original-Received: from chene.dit.umontreal.ca ([132.204.246.20]:35343) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OJX1K-0005mi-Iu for emacs-devel@gnu.org; Tue, 01 Jun 2010 15:21:02 -0400 Original-Received: from faina.iro.umontreal.ca (faina.iro.umontreal.ca [132.204.26.177]) by chene.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id o51JKwGU000709; Tue, 1 Jun 2010 15:20:58 -0400 Original-Received: by faina.iro.umontreal.ca (Postfix, from userid 20848) id 21441705E4; Tue, 1 Jun 2010 15:20:58 -0400 (EDT) In-Reply-To: <4C052F8C.8030208@gmx.at> (martin rudalics's message of "Tue, 01 Jun 2010 18:04:28 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 1 Rules triggered RV3547=0 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) 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:125433 Archived-At: >>> We could make this customizable. >> No, we want instead to try and think in each case which behavior would >> make more sense. > We probably all agree that a window should not show a buffer visible > elsewhere when its buffer is killed or buried and its window-local > buffer list contains no other buffer. Makes sense, yes/ > Maybe we also agree that we should show such a buffer when the window > was "stolen" by a construct like `with-temp-buffer'. with-temp-buffer is probably a poor example since it doesn't affect windows, but if you mean something like with-output-to-temp-buffer, then yes, we probably all agree. > However, I'm afraid that there's no good approximation for the remaining > cases. There are people used to edit large buffers by showing related > sections in two or more windows. And there are people who don't do > that. [The latter group should not be affected much by the new behavior > since we expect them to never show the same buffer twice at the same > time. But I'm not sure whether the use of `split-window' runs counter > to such an assumption.] We can solve each case as it shows up. E.g. for the split-window case (i.e. buffer shown in 2 windows only because that's what split-window does, but the user then immediately switches to some other buffer), we should try and find a way to capture the user's intention. E.g. "immediately" after split-window, any set-window-buffer will not push the current buffer on the buffer-list of that window. >> And maybe you're right that in "all" cases, trying to restore the >> previous window state is TRT, rather than choosing some >> non-shown buffer. > I cannot be right since I never proposed that ;-) I thought you suggested to have a config var to decide whether to use the current heuristic, or to use another heuristic which prefers buffers from the window's buffer-list regardless of whether they are shown elsewhere. Isn't that what you meant in: >> we should think about how we can tell which is >> the better choice in a given situation. > We could make this customizable. -- Stefan