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: Wed, 7 Dec 2005 16:03:17 -0800 Message-ID: References: <87r78ooe3s.fsf@jurta.org> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1134001974 27377 80.91.229.2 (8 Dec 2005 00:32:54 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 8 Dec 2005 00:32:54 +0000 (UTC) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Dec 08 01:32:53 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1Ek9iF-00043N-Qy for ged-emacs-devel@m.gmane.org; Thu, 08 Dec 2005 01:32:44 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ek9iV-0000aj-Oc for ged-emacs-devel@m.gmane.org; Wed, 07 Dec 2005 19:32:59 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Ek9GD-0005NQ-FF for emacs-devel@gnu.org; Wed, 07 Dec 2005 19:03:45 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Ek9G9-0005LI-4O for emacs-devel@gnu.org; Wed, 07 Dec 2005 19:03:42 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ek9G7-0005Km-F2 for emacs-devel@gnu.org; Wed, 07 Dec 2005 19:03:39 -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 1Ek9H2-0000Vv-Sq for emacs-devel@gnu.org; Wed, 07 Dec 2005 19:04:37 -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 jB803JXM000793 for ; Wed, 7 Dec 2005 17:03: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 jB803Jc2019224 for ; Wed, 7 Dec 2005 17:03:19 -0700 Original-Received: from dradamslap (dhcp-4op11-4op12-west-130-35-178-179.dhcpamer.oracle.com [130.35.178.179]) by rgmsgw301.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with SMTP id jB803IKK019216 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Wed, 7 Dec 2005 17:03: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: <87r78ooe3s.fsf@jurta.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Importance: Normal 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:47184 Archived-At: > I'd repeat, though, that it would make sense for the default > value of the option to come from the value of pop-up-frames: > > 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. > > That way, people who use one-buffer-per-frame-by-default > would not need to change anything, beyond setting > pop-up-frames = t. I think that covers most > (but not all) people who set pop-up-frames = t. I still don't understand the need for a new option for one-buffer-per-frame configuration. When a new frame is created due to pop-up-frames=t, its frame-local buffer-list contains exactly one buffer which is the current buffer. So (buffer-list) is an exact equivalent of (buffer-list t). I have trouble following this thread, because there are apparently multiple changes being made now, some of which are bug fixes. The original discussion that interested me concerned the problem of using the frame-local buffer list, instead of the global list, for Buffer Menu. One bug involved inappropriate additions to a frame's local buffer list. I don't know if fixing that bug takes care of my concern or not - frankly, I'm a bit lost now. I believe that Karoly is on top of it all, however. He understands my original concern, so I'm sure he'll DTRT wrt pop-up-frames. I'm OK with whatever is done to take my original concern into account. IOW, I don't care if there is a new option to take care of it, or a bug fix, or whatever it takes. I just don't want the order of the buffers in the Buffer Menu to change drastically, depending on which buffer (frame) I call it from. I would like to be able to treat the Buffer Menu's chronological sort as a global ordering, which ignores the frame residence of buffers altogether. WRT one-buffer-per-frame: I mentioned one-buffer-per-frame-_by-default_. I do change buffers in a given frame, so the local buffer list does change. The behavior I described is generally one buffer _at a time_ per frame (but I do occasionally use more than one window (buffer) at a time). In any case, I never care about the different chronological buffer orderings in different frames.