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: bug#4293: 23.1; use pop-to-buffer, not switch...other-window, in bookmark.el Date: Wed, 02 Sep 2009 18:45:56 +0200 Message-ID: <4A9EA144.80708@gmx.at> References: <4A9E41E3.1000201@gmx.at> <0EDDA64C33FD4884B064564DC880B5F3@us.oracle.com> <4A9E9387.5010106@gmx.at> <8BA10FD9BFF44AD3BDCE2184D7577DF9@us.oracle.com> Reply-To: martin rudalics , 4293@emacsbugs.donarmstrong.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 1251911238 7254 80.91.229.12 (2 Sep 2009 17:07:18 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 2 Sep 2009 17:07:18 +0000 (UTC) Cc: 4293@emacsbugs.donarmstrong.com To: Drew Adams Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Sep 02 19:07:11 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 1MitIc-0005tS-MT for geb-bug-gnu-emacs@m.gmane.org; Wed, 02 Sep 2009 19:07:11 +0200 Original-Received: from localhost ([127.0.0.1]:60520 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MitIc-0007kR-3j for geb-bug-gnu-emacs@m.gmane.org; Wed, 02 Sep 2009 13:07:10 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MitIX-0007k3-1d for bug-gnu-emacs@gnu.org; Wed, 02 Sep 2009 13:07:05 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MitIS-0007hu-EZ for bug-gnu-emacs@gnu.org; Wed, 02 Sep 2009 13:07:04 -0400 Original-Received: from [199.232.76.173] (port=33361 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MitIS-0007hn-8S for bug-gnu-emacs@gnu.org; Wed, 02 Sep 2009 13:07:00 -0400 Original-Received: from rzlab.ucr.edu ([138.23.92.77]:51260) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MitIR-0005jL-GN for bug-gnu-emacs@gnu.org; Wed, 02 Sep 2009 13:06: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 n82H6vOC000561; Wed, 2 Sep 2009 10:06:57 -0700 Original-Received: (from debbugs@localhost) by rzlab.ucr.edu (8.14.3/8.14.3/Submit) id n82Go4f6029185; Wed, 2 Sep 2009 09:50:04 -0700 Resent-Date: Wed, 2 Sep 2009 09:50:04 -0700 X-Loop: owner@emacsbugs.donarmstrong.com Resent-From: martin rudalics Resent-To: bug-submit-list@donarmstrong.com Resent-CC: Emacs Bugs 2Resent-Date: Wed, 02 Sep 2009 16:50: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.125190996628614 (code B ref 4293); Wed, 02 Sep 2009 16:50:04 +0000 Original-Received: (at 4293) by emacsbugs.donarmstrong.com; 2 Sep 2009 16:46:06 +0000 X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. Original-Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with SMTP id n82Gk4Jk028607 for <4293@emacsbugs.donarmstrong.com>; Wed, 2 Sep 2009 09:46:06 -0700 Original-Received: (qmail invoked by alias); 02 Sep 2009 16:45:58 -0000 Original-Received: from 62-47-53-203.adsl.highway.telekom.at (EHLO [62.47.53.203]) [62.47.53.203] by mail.gmx.net (mp046) with SMTP; 02 Sep 2009 18:45:58 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1/J8ihNXZbJpj1rkZbgwD7ckN4FIzfxe2cvSqy8Fq SYrYKmt7bJ1kHZ User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) In-Reply-To: <8BA10FD9BFF44AD3BDCE2184D7577DF9@us.oracle.com> X-Y-GMX-Trusted: 0 X-FuHaFi: 0.65 X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) Resent-Date: Wed, 02 Sep 2009 13:07: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:30738 Archived-At: > 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. The body of `switch-to-buffer-other-window' is deceptively simple (let ((pop-up-windows t) same-window-buffer-names same-window-regexps) (pop-to-buffer buffer-or-name t norecord))) so let's look into this: - `pop-up-windows' t means it can pop-up a new window in the selected frame. I suppose we don't care about this. - `same-window-buffer-names' and `same-window-regexps' make sure the selected window is not chosen. So we don't care about these either. - The `buffer-or-name' and `norecord' arguments for `pop-to-buffer' are the same as for `pop-to-buffer'. We don't care about them. - The `other-window' argument set to t is the only one that would differ with respect to a plain `pop-to-buffer'. But we need it in order to not reuse the selected window, just as the names of the bookmark functions indicate. So we won't care about these either. All that's left are variables like `display-buffer-reuse-frames' which are handled the same way by `display-buffer'. >> 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). So show me where there's a difference for the `t' case. > (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). Then why does this not work for `switch-to-buffer-other-window'? >> 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. It does so here. > (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. I suppose you redefined some of the involved functions in a non-standard manner. Please have a look. Otherwise, we need someone else to confirm the behavior you report. I can't reproduce it. martin