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: Tue, 01 Jun 2010 18:04:28 +0200 Message-ID: <4C052F8C.8030208@gmx.at> References: <4BB4CF6B.2000007@alice.it> <87r5m4hz39.fsf@mail.jurta.org> <4BD40821.70808@gmx.at> <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> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1275408644 17235 80.91.229.12 (1 Jun 2010 16:10:44 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 1 Jun 2010 16:10:44 +0000 (UTC) Cc: Juri Linkov , Emacs To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Jun 01 18:10:43 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 1OJU35-0007x1-Fi for ged-emacs-devel@m.gmane.org; Tue, 01 Jun 2010 18:10:39 +0200 Original-Received: from localhost ([127.0.0.1]:54470 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OJU34-0004Rx-Hs for ged-emacs-devel@m.gmane.org; Tue, 01 Jun 2010 12:10:38 -0400 Original-Received: from [140.186.70.92] (port=42904 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OJTxI-0008Nz-KO for emacs-devel@gnu.org; Tue, 01 Jun 2010 12:04:41 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OJTxD-0000CC-LG for emacs-devel@gnu.org; Tue, 01 Jun 2010 12:04:40 -0400 Original-Received: from mail.gmx.net ([213.165.64.20]:34218) by eggs.gnu.org with smtp (Exim 4.69) (envelope-from ) id 1OJTxD-0000Bj-8Z for emacs-devel@gnu.org; Tue, 01 Jun 2010 12:04:35 -0400 Original-Received: (qmail invoked by alias); 01 Jun 2010 16:04:32 -0000 Original-Received: from 62-47-42-154.adsl.highway.telekom.at (EHLO [62.47.42.154]) [62.47.42.154] by mail.gmx.net (mp002) with SMTP; 01 Jun 2010 18:04:32 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1/s5jZBr4jsbrsuSLRCCQO7T4ZQq339dOgymJbVCN b7sMQDjmwZYE1g User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) In-Reply-To: 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:125430 Archived-At: > So you're saying that C-x k's heuristic should be to try and restore the > previous window state? I guess that could make sense, yes. I was saying that _if_ we want to fix the behavior to handle Juri's case, we'd have to call `other-buffer' with VISIBLE_OK non-nil (or something the like). >> 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. Maybe we also agree that we should show such a buffer when the window was "stolen" by a construct like `with-temp-buffer'. 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.] > 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 ;-) martin