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 11:23:19 -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 1133206025 32505 80.91.229.2 (28 Nov 2005 19:27:05 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 28 Nov 2005 19:27:05 +0000 (UTC) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Nov 28 20:27:03 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1EgobN-0000kH-Hk for ged-emacs-devel@m.gmane.org; Mon, 28 Nov 2005 20:23:49 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EgobM-0002OB-Ld for ged-emacs-devel@m.gmane.org; Mon, 28 Nov 2005 14:23:48 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Egob0-0002N4-F1 for emacs-devel@gnu.org; Mon, 28 Nov 2005 14:23:26 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Egoay-0002KC-I9 for emacs-devel@gnu.org; Mon, 28 Nov 2005 14:23:26 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Egoay-0002Jn-A3 for emacs-devel@gnu.org; Mon, 28 Nov 2005 14:23:24 -0500 Original-Received: from [148.87.122.30] (helo=rgminet01.oracle.com) by monty-python.gnu.org with esmtp (TLS-1.0:DHE_RSA_3DES_EDE_CBC_SHA:24) (Exim 4.34) id 1Egoax-0002NU-VL for emacs-devel@gnu.org; Mon, 28 Nov 2005 14:23:24 -0500 Original-Received: from rgmsgw301.us.oracle.com (rgmsgw301.us.oracle.com [138.1.186.50]) by rgminet01.oracle.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id jASJNKdc011581 for ; Mon, 28 Nov 2005 12:23:20 -0700 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 jASJNKhq030020 for ; Mon, 28 Nov 2005 12:23:20 -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 jASJNJK1030011 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 28 Nov 2005 12:23:19 -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:46714 Archived-At: > For people, like me, who use pop-up-frames =3D t, this means that = the > order is usually different, depending on what _buffer_ you call it > from. > I can live with that reordering behavior, I guess. But, it might = be > best if, as before, the same order were used for the buffer menu, > regardless of which frame you call it from. I'm not sure about = that > (hence, "might be") - what do others think? =20 Well, it might be question a personal preference. I usually sort my frames thematically (one for email, one for coding, etc), so a local buffer list makes much more sense. It also seems like the only reasonable behaviour in a multi-display environment.=20 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. I don't think that this question is as much a "question of personal = preference" as it is a question of the value of pop-up-frames (which is = a question of personal preference, of course). I think that people who = use pop-up-frames =3D t will be confused or annoyed by the new behavior = - but I'll ask again: "What do others think?" =20 The iswitchb package has a similar case, and it provides the iswitchb-use-frame-buffer-list variable to let the user decide. =20 Is the reordering really inconvenient with pop-up-frames, or is it just surprising at first? 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. Would = you be just "surprised" or also "annoyed" by such behavior? I haven't = played with the new behavior much, but I think I'll be annoyed by it. 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 Also, if someone has gone to the trouble of sorting the buffer menu, and = then calls it again, from a different frame, your change will require = manually resorting it, just to get back the last sort order. I would = prefer that the buffer menu not get resorted this way (order changed) = behind my back. =20 > I'm also curious how this change actually fixes the problem = reported > for tty - doesn't function `buffer-list' still list all buffers, = so > that all get listed in the buffer menu? I don't see where the code > does anything different for the tty case. =20 AFAICS the submitter only wanted a local ordering; he did not want = to eliminate references to buffers on other displays. That was not my reading of the OP, but the behavior for tty makes no = difference to me. Thanks for confirming that my reading of the code was = correct, in any case.