From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.devel Subject: RE: Buffer listing in multiple frames/ttys Date: Tue, 29 Nov 2005 16:20:28 -0800 Message-ID: References: <200511292335.jATNZY316413@raven.dms.auburn.edu> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1133310647 27015 80.91.229.2 (30 Nov 2005 00:30:47 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 30 Nov 2005 00:30:47 +0000 (UTC) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Nov 30 01:30:36 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1EhFr8-0007mw-3M for ged-emacs-devel@m.gmane.org; Wed, 30 Nov 2005 01:29:54 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EhFr7-0002Dw-5q for ged-emacs-devel@m.gmane.org; Tue, 29 Nov 2005 19:29:53 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1EhFiC-0000Pt-KA for emacs-devel@gnu.org; Tue, 29 Nov 2005 19:20:41 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1EhFiB-0000PU-GU for emacs-devel@gnu.org; Tue, 29 Nov 2005 19:20:39 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EhFiA-0000PM-7k for emacs-devel@gnu.org; Tue, 29 Nov 2005 19:20:38 -0500 Original-Received: from [141.146.126.228] (helo=agminet01.oracle.com) by monty-python.gnu.org with esmtp (TLS-1.0:DHE_RSA_3DES_EDE_CBC_SHA:24) (Exim 4.34) id 1EhFi9-0003AU-6k for emacs-devel@gnu.org; Tue, 29 Nov 2005 19:20:38 -0500 Original-Received: from rgmsgw300.us.oracle.com (rgmsgw300.us.oracle.com [138.1.186.49]) by agminet01.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id jAU0ZoPj023222 for ; Tue, 29 Nov 2005 18:35:51 -0600 Original-Received: from rgmsgw300.us.oracle.com (localhost [127.0.0.1]) by rgmsgw300.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id jAU0KXvv029167 for ; Tue, 29 Nov 2005 17:20:33 -0700 Original-Received: from dradamslap (dhcp-amer-rmdc-csvpn-gw4-141-144-96-169.vpn.oracle.com [141.144.96.169]) by rgmsgw300.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with SMTP id jAU0KXTD029157 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Tue, 29 Nov 2005 17:20:33 -0700 Original-To: X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <200511292335.jATNZY316413@raven.dms.auburn.edu> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE 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:46788 Archived-At: Lorentey Karoly wrote: I agree that there is no point in having frame-local buffer lists when pop-up-frames is set to t, so I propose in that case we continue to use the global buffer-list, as before. `pop-up-frames' is mainly a way of preventing help buffers and such from messing up window configurations. I don't really agree, but I'm not sure my disagreement is important here. My guess (why? I don't know) is that most people who set `pop-up-frames' = t are trying to get a one-buffer-per-frame behavior for Emacs. That is not as easy as simply setting that variable, however, so such behavior cannot be said to be the purpose of that variable, admittedly. `C-x b' still gives buffers in the selected frame. `M-x buffer-menu' still gives the Buffer Menu in the selected frame. ... The frame local buffer list only makes no sense if you not only set pop-up-frames to t, but, much more importantly, always use C-x 5 b instead of C-x b, as Drew apparently does. (I believe that he must have rebound C-x b to run `C-x 5 b') But that is highly personal usage. I use C-x 4 b (4 works like 5, if pop-up-frames is t) when I don't want to replace the current buffer - just as you might use it to open a buffer in another window: no difference. I doubt that I work much differently from others - I just use frames in place of windows. The point is not that I don't reuse a frame for a different buffer - it is that I have only one buffer per frame (most of the time) - that is, I use frames like most people use Emacs windows. If you keep that analogy in mind, you'll understand why this change makes little sense for my use case. Whenever I don't bother to create a new frame (e.g. I use `C-x d' instead of `C-x 4 d'), I don't _care_ about what was in the frame before (I use `C-x C-v' too). In that case (as in all other cases), I don't care about the frame-local buffer list - I don't want to see it or have its order taken into account anywhere. In short, I use frames pretty much like most people use Emacs windows. You wouldn't find a window-local buffer list useful, would you? You wouldn't want the Buffer Menu to be ordered in any way based on that, would you? That's the point. (BTW - In order to make frames behave well, I also make special buffers (*...*) use dedicated windows, and redefine `switch-to-buffer' to use a different window if the current window is dedicated, and jump through a few other hoops.) On the other hand, if you do not use separate frames systematically for separate themes, then usually the least important buffers are the _globally_ least recent ones. So in that case you might prefer the old behavior, regardless of the value of `pop-up-frames'. So, should I apply this patch or not? :-) For the reasons explained above, I would prefer a user option, with the new behavior as default. In other words, I would prefer the following patch, which I could install if we decide to do that: + (defcustom Buffer-menu-use-frame-buffer-list t + "If non-nil, the Buffer Menu uses the selected frame's buffer list. + If nil, it uses the global buffer list. This variable matters if + the Buffer Menu is sorted by visited order, as it is by default." Yes, I, at least, would prefer having the option. Thanks. I still believe that most people who use pop-up-frames = t will want to set this option to nil (so, they would prefer that that behavior be the default for non-nil pop-up-frames), but I don't mind setting the option to get the old behavior.