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: bug#17719: 24.4.50; REGRESSION: `switch-to-buffer-other-frame' does not use other frame Date: Fri, 6 Jun 2014 14:32:20 -0700 (PDT) Message-ID: References: <<0e1661a2-0661-4f9a-a2cf-5bde51ffdb5f@default>> <<83wqct3jy6.fsf@gnu.org>> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1402090417 8052 80.91.229.3 (6 Jun 2014 21:33:37 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 6 Jun 2014 21:33:37 +0000 (UTC) Cc: 17719@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Jun 06 23:33:30 2014 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Wt1lO-0007Ym-5k for geb-bug-gnu-emacs@m.gmane.org; Fri, 06 Jun 2014 23:33:26 +0200 Original-Received: from localhost ([::1]:49644 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wt1lN-0001kk-Kw for geb-bug-gnu-emacs@m.gmane.org; Fri, 06 Jun 2014 17:33:25 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55004) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wt1lC-0001kV-82 for bug-gnu-emacs@gnu.org; Fri, 06 Jun 2014 17:33:22 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Wt1l0-0000p5-Fn for bug-gnu-emacs@gnu.org; Fri, 06 Jun 2014 17:33:14 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:48770) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wt1l0-0000oz-D4 for bug-gnu-emacs@gnu.org; Fri, 06 Jun 2014 17:33:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1Wt1kz-0002oy-QB for bug-gnu-emacs@gnu.org; Fri, 06 Jun 2014 17:33:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 06 Jun 2014 21:33:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 17719 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 17719-submit@debbugs.gnu.org id=B17719.140209035410787 (code B ref 17719); Fri, 06 Jun 2014 21:33:01 +0000 Original-Received: (at 17719) by debbugs.gnu.org; 6 Jun 2014 21:32:34 +0000 Original-Received: from localhost ([127.0.0.1]:39919 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Wt1kX-0002nv-AN for submit@debbugs.gnu.org; Fri, 06 Jun 2014 17:32:33 -0400 Original-Received: from aserp1040.oracle.com ([141.146.126.69]:37023) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Wt1kU-0002na-FB for 17719@debbugs.gnu.org; Fri, 06 Jun 2014 17:32:31 -0400 Original-Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s56LWNmB009041 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 6 Jun 2014 21:32:24 GMT Original-Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id s56LWL3F002900 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 6 Jun 2014 21:32:22 GMT Original-Received: from abhmp0018.oracle.com (abhmp0018.oracle.com [141.146.116.24]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s56LWL4j007356; Fri, 6 Jun 2014 21:32:21 GMT In-Reply-To: <<83wqct3jy6.fsf@gnu.org>> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.8 (707110) [OL 12.0.6691.5000 (x86)] X-Source-IP: ucsinet22.oracle.com [156.151.31.94] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:90152 Archived-At: > > This regression seems to have been introduced in Emacs 23. There is no > > such problem in Emacs 22.3 and prior. > > emacs -Q > > Visit some file, say foo.el, alone in the frame. > > C-x 2 C-x 3 ; show the buffer in 3 windows > > C-x 5 b foo.el ; type the same buffer name, explicitly > > One of the other windows on the same frame is selected. >=20 > That's the intended behavior, AFAIK. The behavior changed in one of > the last versions (not sure exactly which one, but could very well be > Emacs 23). Ah yes. I remember now. This is not the first bug report about this. Mark Kennedy filed a report entitled "switch-to-buffer-other-frame fails to pop-up window" on Dec 3, 2007 (before we used the bug tracker, I believe). I even said then that I liked the new behavior (!). However, I wonder now if that shouldn't be the behavior just for `C-x 4 b' with non-nil `pop-up-frames', and not for `C-x 5 b'. Just a thought. The doc of `pop-up-frames' used to say that it:=20 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. (Martin's emphasis, from the cited thread.) IOW, it was documented as not necessarily using another frame. The combination of non-nil `pop-up-frames' with `switch-to-buffer-other-window' would then not always impose using a separate frame. (However, the doc of `p-u-f' has changed to say now that it always uses a separate frame (for graphic displays).) Interactively, a user can use `C-x 5 2' to get the desired new-frame behavior (but that means s?he needs to know about the exceptional case and remember another key sequence to cover it). And if s?he wants to see similar names of other buffers before choosing, then s?he needs to use first `C-x 5 b' (or similar) to see the names, then `C-g', then `C-x 5 2' if the one s?he wants is in fact the current buffer (e.g., after verifying that what s?he wants is not some other buffer with a similar name). Admittedly, those are only minor inconveniences. In any case, non-interactively things are not so simple. The circumstance leading to the exceptional behavior is somewhat complicated: 1. Current buffer is in more than one window of the selected frame. 2. Current buffer is not in any other frame. If either (1) or (2) is not true then the a new frame is created and selected for the current buffer. IOW, this special case means special-casing one's code, if you want it to switch to an arbitrary buffer (e.g., a BUFFER arg) in another frame (always). So regardless of whether we make a change for interactive use, I wonder if non-interactive (switch-to-buffer-other-frame BUFFER) shouldn't always create a new frame for BUFFER when it is not already shown in another frame, even when BUFFER is the current buffer. Finally, even if you decide not to change the current behavior, it should be documented. Anyone reading the doc will expect that (switch-to-buffer-other-frame BUFFER) always, not just sometimes, selects the BUFFER in another frame, and that is not the case. For the current buffer, it is sometimes the case and sometimes not the case.