From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Luc Teirlinck Newsgroups: gmane.emacs.devel Subject: Re: Buffer listing in multiple frames/ttys Date: Tue, 29 Nov 2005 12:12:07 -0600 (CST) Message-ID: <200511291812.jATIC7D13956@raven.dms.auburn.edu> References: NNTP-Posting-Host: main.gmane.org X-Trace: sea.gmane.org 1133339379 28203 80.91.229.2 (30 Nov 2005 08:29:39 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 30 Nov 2005 08:29:39 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Nov 30 09:29:21 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1EhMf7-0002oP-MM for ged-emacs-devel@m.gmane.org; Wed, 30 Nov 2005 08:46:01 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EhMf5-0000R8-EN for ged-emacs-devel@m.gmane.org; Wed, 30 Nov 2005 02:45:55 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1EhM9g-0001lQ-IG for emacs-devel@gnu.org; Wed, 30 Nov 2005 02:13:28 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1EhM9e-0001l7-Py for emacs-devel@gnu.org; Wed, 30 Nov 2005 02:13:27 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EhM9d-0001l1-RA for emacs-devel@gnu.org; Wed, 30 Nov 2005 02:13:25 -0500 Original-Received: from [199.232.41.67] (helo=mx20.gnu.org) by monty-python.gnu.org with esmtp (TLS-1.0:RSA_ARCFOUR_SHA:16) (Exim 4.34) id 1EhM9d-0004xz-Lz for emacs-devel@gnu.org; Wed, 30 Nov 2005 02:13:25 -0500 Original-Received: from [131.204.53.104] (helo=manatee.dms.auburn.edu) by mx20.gnu.org with esmtp (Exim 4.34) id 1Eh9ys-0000Dj-VL for emacs-devel@gnu.org; Tue, 29 Nov 2005 13:13:31 -0500 Original-Received: from raven.dms.auburn.edu (raven.dms.auburn.edu [131.204.53.29]) by manatee.dms.auburn.edu (8.13.3+Sun/8.13.3) with ESMTP id jATID97p010815; Tue, 29 Nov 2005 12:13:09 -0600 (CST) Original-Received: (from teirllm@localhost) by raven.dms.auburn.edu (8.11.7p1+Sun/8.11.7) id jATIC7D13956; Tue, 29 Nov 2005 12:12:07 -0600 (CST) X-Authentication-Warning: raven.dms.auburn.edu: teirllm set sender to teirllm@dms.auburn.edu using -f Original-To: lorentey@elte.hu In-reply-to: X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0.1 (manatee.dms.auburn.edu [131.204.53.104]); Tue, 29 Nov 2005 12:13:10 -0600 (CST) 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:46802 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. `C-x b' still gives buffers in the selected frame. `M-x buffer-menu' still gives the Buffer Menu in the selected frame. Granted `C-x C-b' pops up the Buffer Menu in a separate frame (and selects it, which seems strange). But if you auto-revert the Buffer Menu, then after at most auto-revert-interval (default 5) seconds, a displayed Buffer Menu frame will automatically update for the currently 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. 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: ===File ~/buff-menu-diff==================================== *** buff-menu.el 28 Nov 2005 14:10:16 -0600 1.95 --- buff-menu.el 29 Nov 2005 11:27:05 -0600 *************** *** 89,94 **** --- 89,102 ---- :type 'number :group 'Buffer-menu) + (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." + :type 'boolean + :group 'Buffer-menu + :version "22.1") + ;; This should get updated & resorted when you click on a column heading (defvar Buffer-menu-sort-column nil "*2 for sorting by buffer names. 5 for sorting by file names. *************** *** 722,728 **** (if (memq c '(?\n ?\s)) c underline)) header))))) ;; Collect info for every buffer we're interested in. ! (dolist (buffer (or buffer-list (buffer-list (selected-frame)))) (with-current-buffer buffer (let ((name (buffer-name)) (file buffer-file-name)) --- 730,739 ---- (if (memq c '(?\n ?\s)) c underline)) header))))) ;; Collect info for every buffer we're interested in. ! (dolist (buffer (or buffer-list ! (buffer-list ! (when Buffer-menu-use-frame-buffer-list ! (selected-frame))))) (with-current-buffer buffer (let ((name (buffer-name)) (file buffer-file-name)) ============================================================