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, 02 Jun 2010 14:59:42 +0200 Message-ID: <4C0655BE.2060203@gmx.at> 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=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1275483600 1610 80.91.229.12 (2 Jun 2010 13:00:00 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 2 Jun 2010 13:00:00 +0000 (UTC) Cc: Juri Linkov , Emacs To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jun 02 14:59:58 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 1OJnY5-0005Uj-Mw for ged-emacs-devel@m.gmane.org; Wed, 02 Jun 2010 14:59:58 +0200 Original-Received: from localhost ([127.0.0.1]:40835 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OJnY4-0006Qm-VJ for ged-emacs-devel@m.gmane.org; Wed, 02 Jun 2010 08:59:57 -0400 Original-Received: from [140.186.70.92] (port=59688 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OJnXx-0006Qg-Vn for emacs-devel@gnu.org; Wed, 02 Jun 2010 08:59:51 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OJnXw-000367-Qt for emacs-devel@gnu.org; Wed, 02 Jun 2010 08:59:49 -0400 Original-Received: from mail.gmx.net ([213.165.64.20]:48634) by eggs.gnu.org with smtp (Exim 4.69) (envelope-from ) id 1OJnXw-00035J-Ff for emacs-devel@gnu.org; Wed, 02 Jun 2010 08:59:48 -0400 Original-Received: (qmail invoked by alias); 02 Jun 2010 12:59:45 -0000 Original-Received: from 62-47-61-98.adsl.highway.telekom.at (EHLO [62.47.61.98]) [62.47.61.98] by mail.gmx.net (mp055) with SMTP; 02 Jun 2010 14:59:45 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1+1tZARVIW1bfFWYzQbS64ieej9ykttVBbu9tvir3 ME9HEHcsNr6H4z 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:125451 Archived-At: >> 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, That's what I meant. > then > yes, we probably all agree. Tracing `with-output-to-temp-buffer' is a pain. I suppose temp_output_buffer_show needs some reserved value for the second argument of `display-buffer' so the latter can set up the window-local buffer list appropriately. > 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. That's precisely the case I had in mind. I have no idea how and why people use `split-window'. Hardly always to show the same buffer twice. But I don't even know how I use it myself. > E.g. "immediately" after split-window, any set-window-buffer will not > push the current buffer on the buffer-list of that window. Aren't there too many ways to make this `set-window-buffer' happen? One of the simplest is `next-buffer' which does `bury-buffer' for the old buffer so it won't create any problems. But what if the user decides to consult some buffer switching application that pops up a window with suggestions? > 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. Not really. I want to avoid that changing the established behavior causes people who do not care anyway ask for getting the old behavior back. If we make this customizable we can concentrate on the criticism of people who really do care. martin