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 13:43:05 -0500 Message-ID: <475842B9.6060001@diamondbackcap.com> References: <47541753.4060505@diamondbackcap.com> <475503CA.70502@gmx.at> <4757023F.6090602@diamondbackcap.com> <47572229.8000803@gmx.at> 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 1196967553 20396 80.91.229.12 (6 Dec 2007 18:59:13 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 6 Dec 2007 18:59:13 +0000 (UTC) Cc: bug-gnu-emacs@gnu.org To: martin rudalics Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Dec 06 19:59: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 1J0LwF-0008Gh-7q for geb-bug-gnu-emacs@m.gmane.org; Thu, 06 Dec 2007 19:59:11 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1J0Lvy-0000aW-Dy for geb-bug-gnu-emacs@m.gmane.org; Thu, 06 Dec 2007 13:58:54 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1J0Lvs-0000aC-IW for bug-gnu-emacs@gnu.org; Thu, 06 Dec 2007 13:58:48 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1J0Lvq-0000Zo-Rt for bug-gnu-emacs@gnu.org; Thu, 06 Dec 2007 13:58:48 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1J0Lvq-0000Zk-OW for bug-gnu-emacs@gnu.org; Thu, 06 Dec 2007 13:58:46 -0500 Original-Received: from outbound-sin.frontbridge.com ([207.46.51.80] helo=outbound7-sin-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 1J0Lvp-0001gM-Ld for bug-gnu-emacs@gnu.org; Thu, 06 Dec 2007 13:58:46 -0500 Original-Received: from outbound7-sin.bigfish.com (localhost.localdomain [127.0.0.1]) by outbound7-sin-R.bigfish.com (Postfix) with ESMTP id 95091127A2F0 for ; Thu, 6 Dec 2007 18:43:30 +0000 (UTC) Original-Received: from mail59-sin-R.bigfish.com (unknown [10.3.40.3]) by outbound7-sin.bigfish.com (Postfix) with ESMTP id 0E5DDD4804C for ; Thu, 6 Dec 2007 18:43:30 +0000 (UTC) Original-Received: from mail59-sin (localhost.localdomain [127.0.0.1]) by mail59-sin-R.bigfish.com (Postfix) with ESMTP id A4EC78E8461 for ; Thu, 6 Dec 2007 18:43:39 +0000 (UTC) X-BigFish: VP X-MS-Exchange-Organization-Antispam-Report: OrigIP: 63.119.74.215; Service: EHS Original-Received: by mail59-sin (MessageSwitch) id 1196966616486489_8640; Thu, 6 Dec 2007 18:43:36 +0000 (UCT) Original-Received: from smtp.diamondbackcap.com (unknown [63.119.74.215]) by mail59-sin.bigfish.com (Postfix) with ESMTP id A57A51510484 for ; Thu, 6 Dec 2007 18:42:16 +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 13:43:35 -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 13:43:25 -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 lB6IhEVx015121; Thu, 6 Dec 2007 13:43:24 -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 lB6Ih5Dr026059; Thu, 6 Dec 2007 13:43:10 -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: <47572229.8000803@gmx.at> X-OriginalArrivalTime: 06 Dec 2007 18:43:25.0158 (UTC) FILETIME=[E2542060:01C83837] X-imss-version: 2.049 X-imss-result: Passed X-imss-scores: Clean:98.57929 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:17128 Archived-At: martin rudalics wrote: > > 1) contrast the behavior of 'c-x 5 b' with 'c-x 4 b'. 'c-x 4 b' always forces the creation of two > > different windows, even when displaying the same buffer. 'c-x 5 b' does not always force the > > creation of two frames. > > When you have two windows on the selected frame, w1 is the selected > window and w2 the other one, w2 shows buffer b, and w1 does not show > buffer b, C-x 4 b will simply switch to w2. Thus C-x 4 b and C-x 5 b > behave very similarly. but two windows exist already in your "c-x 4 b" scenario. and if only one window existed, it would be created. the "other window" invariant is maintained regardless of whether it has to create a new window or just switch to an existing one. but "c-x 5 b" behaves like "c-x 4 b" in the single-frame, two-window scenario you described above. it does *not* cause a second frame to be created. it just switches to w2 without creating a new frame. the "other frame" invariant is *not* maintained. > > > 2) one might guess that 'switch-to-buffer-other-frame' is essentially a wrapper that > > sets 'pop-up-frames' to 't' and then calls display-buffer (and it is). > > while the behavior of display-buffer is meticulously documented, the observed > > behavior clashes with the documentation for 'pop-up-frames'. now if it were > > called "maybe-pop-up-frames" or "frequently-pop-up-frames", i wouldn't feel > > so bad, but... :-). > > The documentation of `pop-up-frames' in the Elisp manual appears > correct: > > -- User Option: pop-up-frames > This variable controls whether `display-buffer' makes new frames. > If it is non-`nil', `display-buffer' looks for an existing window > already displaying the desired buffer, on any visible frame. If > it finds one, it returns that window. Otherwise it makes a new > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > frame. The variables `pop-up-windows' and > `split-height-threshold' do not matter if `pop-up-frames' is > non-`nil'. > > The doc-strings of `pop-up-frames' and `switch-to-buffer-other-frame' > are misleading. The former says "*Non-nil means `display-buffer' should > make a separate frame." but fails to explain the semantics of "should". > The latter tells "Switch to buffer buffer in another frame." which is > just silly IMHO. mea culpa. i did not think to look in the elisp doc. > > > so i'm requesting (not demanding :-) a change in behavior. > > > > 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? /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.