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: Thu, 17 Jun 2010 09:58:22 +0200 Message-ID: <4C19D59E.5010402@gmx.at> References: <4BB4CF6B.2000007@alice.it> <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> <87sk56sg6x.fsf@mail.jurta.org> <4C16616C.2070101@gmx.at> <87pqztiafa.fsf@mail.jurta.org> <4C1726D3.2090308@gmx.at> <87pqzsm2m6.fsf@mail.jurta.org> <4C1908ED.6090107@gmx.at> <878w6esntw.fsf@mail.jurta.org> 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 1276761527 646 80.91.229.12 (17 Jun 2010 07:58:47 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 17 Jun 2010 07:58:47 +0000 (UTC) Cc: Stefan Monnier , Emacs To: Juri Linkov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jun 17 09:58:46 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 1OP9zp-0003x1-Lh for ged-emacs-devel@m.gmane.org; Thu, 17 Jun 2010 09:58:45 +0200 Original-Received: from localhost ([127.0.0.1]:42984 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OP9zo-0000Gd-SP for ged-emacs-devel@m.gmane.org; Thu, 17 Jun 2010 03:58:44 -0400 Original-Received: from [140.186.70.92] (port=51764 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OP9zg-0000C6-KE for emacs-devel@gnu.org; Thu, 17 Jun 2010 03:58:37 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OP9za-0003PT-F4 for emacs-devel@gnu.org; Thu, 17 Jun 2010 03:58:36 -0400 Original-Received: from mail.gmx.net ([213.165.64.20]:44650) by eggs.gnu.org with smtp (Exim 4.69) (envelope-from ) id 1OP9za-0003OF-3I for emacs-devel@gnu.org; Thu, 17 Jun 2010 03:58:30 -0400 Original-Received: (qmail invoked by alias); 17 Jun 2010 07:58:27 -0000 Original-Received: from 62-47-32-46.adsl.highway.telekom.at (EHLO [62.47.32.46]) [62.47.32.46] by mail.gmx.net (mp070) with SMTP; 17 Jun 2010 09:58:27 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1/CepBSHujCPqn3VPJnDY9Lp68i7jXOpWF6wmFnla bmoTf8riHNH2za User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) In-Reply-To: <878w6esntw.fsf@mail.jurta.org> 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:126062 Archived-At: > If we don't know the target window in advance, then we can't use > the window-local buffer-list for `read-buffer-to-switch'. In `switch-to-buffer' we usually know the target window. In `switch-to-buffer-other-window' we don't. How distinguish the two? But I'm afraid that the idea of handling window local buffer lists just like the other buffer lists is flawed anyway. For example, when I display a buffer without selecting the window as in `with-output-to-temp-buffer' I do want to update the window local buffer list. When I do `bury-buffer' and the buffer is not displayed in the selected but maybe some other window the buffer will get buried in the selected window and remains the first buffer in the other window. Both make hardly sense either (and are flawed for frame local buffer lists as well). I suppose that for the moment I'll abandon the idea of window local buffer lists and return to them after I have solved some other issues. > This means that you need to store more information for the first > element of the window-local buffer-list, i.e. when popping the > stack of buffers reaches the first element, it should know what to do > after popping the last element: whether to kill the window and > which window to select instead. The problem is that the information contained there might be already stale (the user might have done a lot of things in between). For help windows it makes sense to check whether the window still displays the help buffer and only if it does I proceed according to the information stored in the window parameter. For arbitrary buffers in non-dedicated windows I might just violate the principle of least surprise. martin