From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Mark T. Kennedy" Newsgroups: gmane.emacs.bugs Subject: Re: switch-to-buffer-other-frame fails to pop-up window Date: Thu, 06 Dec 2007 15:11:34 -0500 Message-ID: <47585776.6030604@diamondbackcap.com> References: 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 1196971932 5323 80.91.229.12 (6 Dec 2007 20:12:12 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 6 Dec 2007 20:12:12 +0000 (UTC) Cc: bug-gnu-emacs@gnu.org To: Drew Adams Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Dec 06 21:12:23 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 1J0N53-0006Ga-NJ for geb-bug-gnu-emacs@m.gmane.org; Thu, 06 Dec 2007 21:12:22 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1J0N4m-0006A6-QY for geb-bug-gnu-emacs@m.gmane.org; Thu, 06 Dec 2007 15:12:04 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1J0N4g-00067i-7M for bug-gnu-emacs@gnu.org; Thu, 06 Dec 2007 15:11:58 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1J0N4e-00065z-Qj for bug-gnu-emacs@gnu.org; Thu, 06 Dec 2007 15:11:57 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1J0N4e-00065n-JF for bug-gnu-emacs@gnu.org; Thu, 06 Dec 2007 15:11:56 -0500 Original-Received: from outbound-blu.frontbridge.com ([65.55.251.16] helo=outbound4-blu-R.bigfish.com) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1J0N4e-0005FM-3v for bug-gnu-emacs@gnu.org; Thu, 06 Dec 2007 15:11:56 -0500 Original-Received: from outbound4-blu.bigfish.com (localhost.localdomain [127.0.0.1]) by outbound4-blu-R.bigfish.com (Postfix) with ESMTP id E87C716DA7E1 for ; Thu, 6 Dec 2007 20:11:54 +0000 (UTC) Original-Received: from mail46-blu-R.bigfish.com (unknown [10.1.252.3]) by outbound4-blu.bigfish.com (Postfix) with ESMTP id DC12EAF0052 for ; Thu, 6 Dec 2007 20:11:54 +0000 (UTC) Original-Received: from mail46-blu (localhost.localdomain [127.0.0.1]) by mail46-blu-R.bigfish.com (Postfix) with ESMTP id 9D63E12E0168 for ; Thu, 6 Dec 2007 20:11:54 +0000 (UTC) X-BigFish: VP X-MS-Exchange-Organization-Antispam-Report: OrigIP: 63.119.74.215; Service: EHS Original-Received: by mail46-blu (MessageSwitch) id 1196971914579771_2475; Thu, 6 Dec 2007 20:11:54 +0000 (UCT) Original-Received: from smtp.diamondbackcap.com (unknown [63.119.74.215]) by mail46-blu.bigfish.com (Postfix) with ESMTP id 6ABFBD08309 for ; Thu, 6 Dec 2007 20:11:54 +0000 (UTC) Original-Received: from mail.diamondbackcap.com ([10.21.1.222]) by smtp.diamondbackcap.com with InterScan Messaging Security Suite; Thu, 06 Dec 2007 15:12:04 -0500 Original-Received: from s1.diamondbackcap.corp ([10.21.2.200]) by mail.diamondbackcap.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 6 Dec 2007 15:11:53 -0500 Original-Received: from d1.diamondbackcap.corp (d1.diamondbackcap.corp [10.21.2.1])by s1.diamondbackcap.corp (8.13.6/8.13.6) with ESMTP id lB6KBraE032136; Thu, 6 Dec 2007 15:11:53 -0500 Original-Received: from d1.diamondbackcap.corp (localhost.localdomain [127.0.0.1])by d1.diamondbackcap.corp (8.13.6/8.13.5) with ESMTP id lB6KBYZx002293; Thu, 6 Dec 2007 15:11:38 -0500 User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.8.1.9) Gecko/20071031 Thunderbird/2.0.0.9 Mnenhy/0.7.5.0 In-Reply-To: X-OriginalArrivalTime: 06 Dec 2007 20:11:53.0855 (UTC) FILETIME=[3E8F00F0:01C83844] X-imss-version: 2.049 X-imss-result: Passed X-imss-scores: Clean:71.12161 C:2 M:3 S:5 R:5 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) X-detected-kernel: by monty-python.gnu.org: Linux 2.6, seldom 2.4 (older, 4) 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:17130 Archived-At: interesting that you've weighed in. i read a lot of your code while converting my .emacs from v21 to v22. you've certainly confronted the buffer/window/frame style question in depth. and i'm happily using many of your libraries. Drew Adams wrote: >> 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. i'm not saying that use case isn't valid. i'm saying there is a clash between the word "other" in "switch-to-buffer-other-frame" and that use case. there is no "other" frame in the example martin gave and the use case you prefer. and i'm supporting my case by drawing an analogy to the behavior of "c-x 4 b" where two windows are *always* involved. > > 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'. understood. > > 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'. > > you better than anyone should have a feel for the right thing to do. from what i can tell from a pass through the emacsWiki, you're the buffer/window/frame usage style guru. i tend to keep one file (buffer) per frame. i like to have help & grep & apropos and similar things pop up and down within the frame from which they were invoked. but i like "info" and "*Messages*" to be in separate, dedicated frames. i also find it convenient to have more than one top-level "info" frame. what got me started down this entire path was an attempt at providing per-frame help buffers. i was annoyed when an existing help window in frame X changed to the help response i generated when i invoked help in frame Y. i tried to take over 'help-buffer' from help-mode.el in order to hide a per-frame help buffer name in a frame property. but i found that '(selected-frame)' returned the minibuffer frame when 'help-buffer' was invoked rather than the frame from which "help" was invoked (i sent in a separate bug report for that but haven't heard anything about it yet). /mark This communication and any attachments may contain confidential/proprietary information and is intended for information purposes only. It is not an invitation or offer to purchase interests from Diamondback. Any representation to the contrary is unintentional. This communication is intended only for the person(s) to whom it is addressed. If you are not the intended recipient you are hereby notified that you have received this document in error and that any review, dissemination, distribution, or copying of this message or any attachments is not permitted. If you have received this in error, please notify the sender immediately by e-mail and delete this message. All e-mails sent to or received from this address will be received by Diamondback's company e-mail system and is subject to a rchival and possible review by someone other than the recipient. This notice is automatically appended to each e-mail message leaving Diamondback.