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#4293: 23.1; use pop-to-buffer, not switch...other-window, in bookmark.el Date: Wed, 2 Sep 2009 09:16:26 -0700 Message-ID: <8BA10FD9BFF44AD3BDCE2184D7577DF9@us.oracle.com> References: <4A9E41E3.1000201@gmx.at> <0EDDA64C33FD4884B064564DC880B5F3@us.oracle.com> <4A9E9387.5010106@gmx.at> Reply-To: Drew Adams , 4293@emacsbugs.donarmstrong.com NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1251908939 31528 80.91.229.12 (2 Sep 2009 16:28:59 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 2 Sep 2009 16:28:59 +0000 (UTC) Cc: 4293@emacsbugs.donarmstrong.com To: "'martin rudalics'" Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Sep 02 18:28:52 2009 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 1MishM-0000cY-8P for geb-bug-gnu-emacs@m.gmane.org; Wed, 02 Sep 2009 18:28:40 +0200 Original-Received: from localhost ([127.0.0.1]:35677 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MishL-0000ex-EX for geb-bug-gnu-emacs@m.gmane.org; Wed, 02 Sep 2009 12:28:39 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Misfp-0007Ou-AY for bug-gnu-emacs@gnu.org; Wed, 02 Sep 2009 12:27:05 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Misfk-0007IE-AZ for bug-gnu-emacs@gnu.org; Wed, 02 Sep 2009 12:27:04 -0400 Original-Received: from [199.232.76.173] (port=38530 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Misfj-0007Hv-Sw for bug-gnu-emacs@gnu.org; Wed, 02 Sep 2009 12:27:00 -0400 Original-Received: from rzlab.ucr.edu ([138.23.92.77]:56029) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1Misfj-00023G-7D for bug-gnu-emacs@gnu.org; Wed, 02 Sep 2009 12:26:59 -0400 Original-Received: from rzlab.ucr.edu (rzlab.ucr.edu [127.0.0.1]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n82GQvod024850; Wed, 2 Sep 2009 09:26:57 -0700 Original-Received: (from debbugs@localhost) by rzlab.ucr.edu (8.14.3/8.14.3/Submit) id n82GP4e0024506; Wed, 2 Sep 2009 09:25:04 -0700 Resent-Date: Wed, 2 Sep 2009 09:25:04 -0700 X-Loop: owner@emacsbugs.donarmstrong.com Resent-From: "Drew Adams" Resent-To: bug-submit-list@donarmstrong.com Resent-CC: Emacs Bugs 2Resent-Date: Wed, 02 Sep 2009 16:25:04 +0000 Resent-Message-ID: Resent-Sender: owner@emacsbugs.donarmstrong.com X-Emacs-PR-Message: followup 4293 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Original-Received: via spool by 4293-submit@emacsbugs.donarmstrong.com id=B4293.125190820723075 (code B ref 4293); Wed, 02 Sep 2009 16:25:04 +0000 Original-Received: (at 4293) by emacsbugs.donarmstrong.com; 2 Sep 2009 16:16:47 +0000 X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. Original-Received: from acsinet12.oracle.com (acsinet12.oracle.com [141.146.126.234]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n82GGj0r023062 for <4293@emacsbugs.donarmstrong.com>; Wed, 2 Sep 2009 09:16:46 -0700 Original-Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by acsinet12.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n82GFwK4020020 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 2 Sep 2009 16:16:00 GMT Original-Received: from abhmt001.oracle.com (abhmt001.oracle.com [141.146.116.10]) by acsinet15.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n82GGbaO022271; Wed, 2 Sep 2009 16:16:37 GMT Original-Received: from dradamslap1 (/130.35.178.194) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 02 Sep 2009 09:16:34 -0700 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <4A9E9387.5010106@gmx.at> Thread-Index: Acor5K95Yps52vmaTBGjaPsbSOcGAgAAhjmQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Source-IP: abhmt001.oracle.com [141.146.116.10] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090203.4A9E9A63.015D:SCFSTAT5015188,ss=1,fgs=0 X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) Resent-Date: Wed, 02 Sep 2009 12:27:04 -0400 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:30737 Archived-At: > >> I'm not sure what the problem is here. > >> `switch-to-buffer-other-window' > >> has a clear purpose - do _not reuse the selected window_ > >> (which is the bookmarks window, IIUC). OTOH > >> `display-buffer-reuse-frames' non-nil > >> should assure that another frame is reused. > > > > Users should not have to customize a global variable, to > > prevent a new frame from being used in particular places like this. > > I thought you wanted to avoid popping up a new frame. At > least in your first mail you said "pop-to-buffer DTRT: > it reuses the existing frame". I do. With pop-up-frames = t, and with a frame alteady showing buffer foo, (switch-to-buffer-other-window 'foo) opens a *new*, additional frame to show foo. That's the bug. pop-to-buffer instead simply navigates to the existing frame, selecting buffer foo there. > > As Stefan says repeatedly (paraphrasing), > > switch-to-buffer-other-window is almost always the wrong > > thing to do, and should be replaced in most places by > > pop-to-buffer. > > > > Use of switch-to-buffer-other-window is a bug in general, > > typically made by someone who doesn't use non-nil pop-up-frames. > > > > In this particular context, there is no reason to use > > switch-to-buffer-other-frame. > > If you have `display-buffer-reuse-frames' set to nil, `pop-to-buffer' > will not reuse another frame displaying that buffer either. Right. This is for the case when it is set to non-nil. For the nil case, I imagine that there is not much difference between pop-to-buffer and switch-to-buffer-other-window (but I don't know, as I've always set it to t). (In fact, I set both display-buffer-reuse-frames and the obsolete (?) display-buffer-reuse-frame to t, just in case. ;-)) I expect that most people who use non-nil pop-up-frames set display-buffer-reuse-frames to t (but I don't know that for a fact). > Please tell which specific detail of `switch-to-buffer-other-window' > you dislike in the present use case. Opening a new frame for the buffer, when there is already an existing frame showing it. In the present use case (and in most use cases), that is uncalled for. Context: non-nil pop-up-frames, non-nil display-buffer-reuse-frames. pop-to-buffer DTRT; switch-to-buffer-other-window does not. (No, we don't want to change the behavior of switch-to-buffer-other-window; that command has its uses. It's just that most or many of the existing calls of switch-to-buffer-other-window should really be calls of pop-to-buffer.) > Note: It can't be the `other-window' argument, > because in that case we'd have to change the names of the respective > bookmark functions. Sorry, I don't what you're saying, there. It's pretty simple, really: When I want to go to a bookmark in another window/frame (which is most of the time I want to go to a bookmark), I don't want to create a new frame for that destination buffer - I just want to go to the frame that's already showing it. Imagine hitting the key to go back to that bookmark several times, off and on over a period of time. You would end up with lots of frames showing that same buffer. Silly. Thx.