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: Mon, 28 Nov 2005 15:12:47 -0800 Message-ID: References: NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Trace: sea.gmane.org 1133219696 15191 80.91.229.2 (28 Nov 2005 23:14:56 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 28 Nov 2005 23:14:56 +0000 (UTC) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Nov 29 00:14:54 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1EgsBg-0007Mm-TP for ged-emacs-devel@m.gmane.org; Tue, 29 Nov 2005 00:13:33 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EgsBf-0007J7-S7 for ged-emacs-devel@m.gmane.org; Mon, 28 Nov 2005 18:13:31 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1EgsBO-0007IP-WE for emacs-devel@gnu.org; Mon, 28 Nov 2005 18:13:15 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1EgsBN-0007Ho-D3 for emacs-devel@gnu.org; Mon, 28 Nov 2005 18:13:14 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EgsBN-0007Hk-92 for emacs-devel@gnu.org; Mon, 28 Nov 2005 18:13:13 -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 1EgsBM-0003Gy-Px for emacs-devel@gnu.org; Mon, 28 Nov 2005 18:13:13 -0500 Original-Received: from rgmsgw301.us.oracle.com (rgmsgw301.us.oracle.com [138.1.186.50]) by agminet01.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id jASNSCTh015161 for ; Mon, 28 Nov 2005 17:28:13 -0600 Original-Received: from rgmsgw301.us.oracle.com (localhost [127.0.0.1]) by rgmsgw301.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id jASND4S8025331 for ; Mon, 28 Nov 2005 16:13:06 -0700 Original-Received: from dradamslap (dradams-lap.us.oracle.com [130.35.177.126]) by rgmsgw301.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with SMTP id jASNCiXk025067 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 28 Nov 2005 16:12:49 -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: 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:46738 Archived-At: Drew Adams writes: > Using pop-up-frames =3D t is quite different from having a set of > fixed, thematic frames. It means that _each_ buffer is opened in a > separate frame. =20 OK, but what is your point? If you don't ever change buffers in a frame, then every time it is selected, its local buffer list will be the same as the global list. Therefore, you shouldn't see any difference between the old and the new code when you call `list-buffers'. That's not what I see.=20 emacs -q load your version of buff-menu.el (setq pop-up-frames t) open several buffers (they will be in separate frames) call buffer-menu from various buffers I see the buffer-menu order change when I call buffer-menu from = different buffers. And it is not just the first (most recent) buffer = that changes. =20 > To understand what your change means for users with pop-up-frames = =3D > t, imagine that the order of the buffer menu were changed each = time > you called it from a different Emacs _window_ - that's what it's > like. =20 I don't need to imagine it: it behaved that way even before the change--`list-buffers' always lists the most recently displayed = buffer first, i.e., the one that was selected at the time of the `list-buffers' invocation. If you run it from a different window, = you get a different list, with that window's buffer in the topmost line. No? Try it with "emacs -Q". The default ordering is chronological, so, yes, the most recent buffer = is always first. The relative order of the other buffers is not changed, = however (currently).=20 Your reordering goes beyond that - the change in order is confusing, = unless one is thinking in terms of multiple buffers per frame and one = knows about the new behavior. That means that the new behavior would = need to be documented explicitly, or else people will not understand = what they see. =20 My change simply groups the buffers that were recently displayed in the current frame closer together. It doesn't fundamentally change the way `list-buffers' works. =20 > So, if it's not too much trouble, I'd suggest having the code test > whether pop-up-frames is non-nil and, if so, using the old > behavior. This would be less confusing and more manageable, for > people using pop-up-frames =3D t. =20 It's not too much trouble at all; I am also willing to back out the change altogether. But are you sure you know how `list-buffers' originally worked? =20 > Also, if someone has gone to the trouble of sorting the buffer = menu, =20 How do you do that? If you mean by `Buffer-menu-sort-column' (clicking on the header line sets that) then the new version doesn't affect that. You are right about that. I was mistaken (see below). =20 > and then calls it again, from a different frame, your change will > require manually resorting it, just to get back the last sort > order. =20 The old code already did that. The new code simply uses a slightly different order. =20 No, I was wrong about needing to manually re-sort. You were correct, = above, when you said that your code doesn't change the sorted behavior. = One didn't need to re-sort before (it stays as last sorted), and one = doesn't need to re-sort after your change. IOW, IIUC, your code only = affects the order for a chronological sort (the default sort). Given that, I can't say I'm annoyed by your change. I was thinking of = the (imagined) need to re-sort. [However, I have my own extension to the column-sorting that adds a Time = column, which shows the `buffer-display-time'. If I sort on that column, = will I need to re-sort? I don't know - is `buffer-display-time' what is = used in your ordering? That's what my "Time" column uses.] BTW, I don't see any way for a user to get back the chronological sort, = after having sorted by some column. This has nothing to do with your = change. Once sorted, the sort order stays until you click to impose a = different sort order - and there is no way to click to get a = chronological sort. I never noticed that before. That seems like a bug (misfeature), to me. = If ever it is fixed, then we _might_ need to review your change - that = is, if it then starts requiring people to manually re-sort. Thanks, Drew =20