From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: lorentey@elte.hu (=?utf-8?Q?L=C5=91rentey_K=C3=A1roly?=) Newsgroups: gmane.emacs.devel Subject: Re: Buffer listing in multiple frames/ttys Date: Mon, 28 Nov 2005 21:48:34 +0100 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 1133219190 13667 80.91.229.2 (28 Nov 2005 23:06:30 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 28 Nov 2005 23:06:30 +0000 (UTC) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Nov 29 00:06:26 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1Egs1y-0001Pz-VS for ged-emacs-devel@m.gmane.org; Tue, 29 Nov 2005 00:03:33 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Egs1x-0004RU-1q for ged-emacs-devel@m.gmane.org; Mon, 28 Nov 2005 18:03:29 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Egs1i-0004R8-IA for emacs-devel@gnu.org; Mon, 28 Nov 2005 18:03:14 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Egs1g-0004Qr-JS for emacs-devel@gnu.org; Mon, 28 Nov 2005 18:03:14 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Egs1g-0004Qo-Ds for emacs-devel@gnu.org; Mon, 28 Nov 2005 18:03:12 -0500 Original-Received: from [212.92.23.158] (helo=ninsei.hu) by monty-python.gnu.org with esmtp (Exim 4.34) id 1Egs1f-0000k7-8T for emacs-devel@gnu.org; Mon, 28 Nov 2005 18:03:12 -0500 Original-Received: from walrus (walrus.inf.elte.hu [157.181.166.149]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by chatsubo.ninsei.hu (Postfix) with ESMTP id F0DAE1ACA1 for ; Tue, 29 Nov 2005 00:03:07 +0100 (CET) Original-Received: by walrus (Postfix, from userid 1000) id 145583A8B9; Tue, 29 Nov 2005 00:03:33 +0100 (CET) Original-To: emacs-devel@gnu.org In-Reply-To: (Drew Adams's message of "Mon, 28 Nov 2005 11:23:19 -0800") Original-Lines: 51 User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/22.0.52 (gnu/linux) 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:46736 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. 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'. > 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. 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". 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. > 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. 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? > Also, if someone has gone to the trouble of sorting the buffer menu, 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. > and then calls it again, from a different frame, your change will > require manually resorting it, just to get back the last sort > order. The old code already did that. The new code simply uses a slightly different order. --=20 K=C3=A1roly