From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.bugs Subject: Re: switch-to-buffer-other-frame fails to pop-up window Date: Wed, 05 Dec 2007 23:11:53 +0100 Message-ID: <47572229.8000803@gmx.at> References: <47541753.4060505@diamondbackcap.com> <475503CA.70502@gmx.at> <4757023F.6090602@diamondbackcap.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1196892879 16409 80.91.229.12 (5 Dec 2007 22:14:39 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 5 Dec 2007 22:14:39 +0000 (UTC) Cc: bug-gnu-emacs@gnu.org To: "Mark T. Kennedy" Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Dec 05 23:14:49 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 1J02Vv-0005yd-V0 for geb-bug-gnu-emacs@m.gmane.org; Wed, 05 Dec 2007 23:14:44 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1J02Vf-0005kZ-63 for geb-bug-gnu-emacs@m.gmane.org; Wed, 05 Dec 2007 17:14:27 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1J02V6-0005CM-Vg for bug-gnu-emacs@gnu.org; Wed, 05 Dec 2007 17:13:53 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1J02V5-0005AX-BV for bug-gnu-emacs@gnu.org; Wed, 05 Dec 2007 17:13:52 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1J02V4-0005AE-Rv for bug-gnu-emacs@gnu.org; Wed, 05 Dec 2007 17:13:50 -0500 Original-Received: from mail.gmx.net ([213.165.64.20]) by monty-python.gnu.org with smtp (Exim 4.60) (envelope-from ) id 1J02V4-0001gE-BB for bug-gnu-emacs@gnu.org; Wed, 05 Dec 2007 17:13:50 -0500 Original-Received: (qmail invoked by alias); 05 Dec 2007 22:13:48 -0000 Original-Received: from N949P014.adsl.highway.telekom.at (EHLO [62.47.62.142]) [62.47.62.142] by mail.gmx.net (mp040) with SMTP; 05 Dec 2007 23:13:48 +0100 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX182j9BUKzA2+0Wd/RWYmLUYrcxW8P98L06Xg7L3md EuI9QcEzMzCJND User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: de-DE, de, en-us, en In-Reply-To: <4757023F.6090602@diamondbackcap.com> X-Y-GMX-Trusted: 0 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:17124 Archived-At: > 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. > 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. > 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?