From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.bugs Subject: RE: switch-to-buffer-other-frame fails to pop-up window Date: Thu, 6 Dec 2007 11:48:52 -0800 Message-ID: References: <475842B9.6060001@diamondbackcap.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1196970645 32076 80.91.229.12 (6 Dec 2007 19:50:45 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 6 Dec 2007 19:50:45 +0000 (UTC) Cc: bug-gnu-emacs@gnu.org To: "Mark T. Kennedy" , "martin rudalics" Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Dec 06 20:50:54 2007 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1J0MkG-0005aA-Am for geb-bug-gnu-emacs@m.gmane.org; Thu, 06 Dec 2007 20:50:52 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1J0Mjz-0000mN-Fr for geb-bug-gnu-emacs@m.gmane.org; Thu, 06 Dec 2007 14:50:35 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1J0Mjt-0000m6-PO for bug-gnu-emacs@gnu.org; Thu, 06 Dec 2007 14:50:29 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1J0Mjt-0000ln-8M for bug-gnu-emacs@gnu.org; Thu, 06 Dec 2007 14:50:29 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1J0Mjt-0000lj-7A for bug-gnu-emacs@gnu.org; Thu, 06 Dec 2007 14:50:29 -0500 Original-Received: from rgminet01.oracle.com ([148.87.113.118]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1J0Mjs-0007ay-Jw for bug-gnu-emacs@gnu.org; Thu, 06 Dec 2007 14:50:28 -0500 Original-Received: from agmgw2.us.oracle.com (agmgw2.us.oracle.com [152.68.180.213]) by rgminet01.oracle.com (Switch-3.2.4/Switch-3.1.6) with ESMTP id lB6JoL20020757; Thu, 6 Dec 2007 12:50:22 -0700 Original-Received: from acsmt350.oracle.com (acsmt350.oracle.com [141.146.40.150]) by agmgw2.us.oracle.com (Switch-3.2.0/Switch-3.2.0) with ESMTP id lB68Hi0h011699; Thu, 6 Dec 2007 12:50:21 -0700 Original-Received: from dhcp-4op11-4op12-west-130-35-178-158.us.oracle.com by acsmt350.oracle.com with ESMTP id 3411176641196970520; Thu, 06 Dec 2007 11:48:40 -0800 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <475842B9.6060001@diamondbackcap.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Brightmail-Tracker: AAAAAQAAAAI= X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Whitelist: TRUE X-detected-kernel: by monty-python.gnu.org: Linux 2.4-2.6 X-BeenThere: bug-gnu-emacs@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:17129 Archived-At: > > > what use case would clash with a change like this? > > > > I don't know, maybe there is one. We could try to provide a third value > > for `pop-up-frames': If it's 'force `display-buffer' would _always_ try > > to display the buffer in a new frame regardless of how many times it is > > already displayed. What do you think? > > that would certainly provide a work-around and make me happy. > > but i'm still curious why the intent of pop-up-frames is overridden by > display-buffer. there has to be a reason lurking somewhere? I like the way it works. The use case is that what one is after is for the buffer to be displayed - that's all. I use non-nil `pop-up-frames' to have `display-buffer' show a buffer for the first time in a new frame, but not to always show a buffer in a new frame. That's what `pop-up-frames' is about. BTW, this is not `display-buffer' _overriding_ `pop-up-frames'; the latter is made for the former. `pop-up-frames' has no meaning other than for `display-buffer'. The relevant doc is the doc string of `display-buffer'. The doc string of `pop-up-frames' tries to take the shortcut of referring to `display-buffer', but it should be clearer about what happens if the buffer is already shown in a frame somewhere. The doc string of `display-buffer' is clear about this: "If `pop-up-frames' is non-nil, make a new frame if no window shows BUFFER." It is the last bit of the logic ("if no window shows BUFFER") that is missing from the doc string of `pop-up-frames'. In principle, we could add a new `force' value for `pop-up-frames'. But there is existing code that tests `pop-up-frames' and assumes the current behavior. In some cases, it uses `pop-up-frames' as a guide to user intentions and practice wrt frames in general. At least some of that code would likely need to be revisited, to see if the test is still sufficient or should be changed to test non-nil and non-`force'.