From drew.adams@oracle.com Sun Aug 30 07:58:46 2009 Received: (at submit) by emacsbugs.donarmstrong.com; 30 Aug 2009 14:58:46 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-2.5 required=4.0 tests=AWL,FOURLA autolearn=no version=3.2.5-bugs.debian.org_2005_01_02 Received: from lists.gnu.org (lists.gnu.org [199.232.76.165]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n7UErCJu007494 for ; Sun, 30 Aug 2009 07:53:14 -0700 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MhlmH-0007Ff-LR for bug-gnu-emacs@gnu.org; Sun, 30 Aug 2009 10:53:10 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Mhlm4-0007Dq-C9 for bug-gnu-emacs@gnu.org; Sun, 30 Aug 2009 10:53:06 -0400 Received: from [199.232.76.173] (port=33811 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Mhlm3-0007Dj-Ti for bug-gnu-emacs@gnu.org; Sun, 30 Aug 2009 10:52:56 -0400 Received: from acsinet12.oracle.com ([141.146.126.234]:31780) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1Mhlm2-0006A2-Hl for bug-gnu-emacs@gnu.org; Sun, 30 Aug 2009 10:52:55 -0400 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 n7UEq09j015631 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sun, 30 Aug 2009 14:52:02 GMT Received: from abhmt012.oracle.com (abhmt012.oracle.com [141.146.116.21]) by acsinet15.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n7UEqa1W004276 for ; Sun, 30 Aug 2009 14:52:36 GMT Received: from dradamslap1 (/141.144.64.128) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 30 Aug 2009 07:52:35 -0700 From: "Drew Adams" To: Subject: 23.1; use pop-to-buffer, not switch...other-window, in bookmark.el Date: Sun, 30 Aug 2009 07:52:34 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcopgYJmaFyxs0vgTPqeWInqy75s7A== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Source-IP: abhmt012.oracle.com [141.146.116.21] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090205.4A9A9233.00FA:SCFSTAT5015188,ss=1,fgs=0 X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 1) In bookmark-jump-other-window and bookmark-bmenu-other-window we call switch-to-buffer-other-window. We should use pop-to-buffer, instead. With non-nil pop-up-frames, switch-to-buffer-other-window creates a new frame each time, even if the destination buffer is already showing in some frame. pop-to-buffer DTRT: it reuses the existing frame. In GNU Emacs 23.1.1 (i386-mingw-nt5.1.2600) of 2009-07-29 on SOFT-MJASON Windowing system distributor `Microsoft Corp.', version 5.1.2600 configured using `configure --with-gcc (4.4)' From rudalics@gmx.at Wed Sep 2 02:59:14 2009 Received: (at 4293) by emacsbugs.donarmstrong.com; 2 Sep 2009 09:59:14 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-4.4 required=4.0 tests=AWL,FOURLA,HAS_BUG_NUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 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 n829xBpD010708 for <4293@emacsbugs.donarmstrong.com>; Wed, 2 Sep 2009 02:59:13 -0700 Received: (qmail invoked by alias); 02 Sep 2009 09:59:05 -0000 Received: from 62-47-58-95.adsl.highway.telekom.at (EHLO [62.47.58.95]) [62.47.58.95] by mail.gmx.net (mp042) with SMTP; 02 Sep 2009 11:59:05 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX18UdNcKnN0UUK2waKA2hWzVUyMPYrrhq3VrbR1q4v /Gf16YwfNKmrZC Message-ID: <4A9E41E3.1000201@gmx.at> Date: Wed, 02 Sep 2009 11:58:59 +0200 From: martin rudalics User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Drew Adams , 4293@debbugs.gnu.org Subject: Re: bug#4293: 23.1; use pop-to-buffer, not switch...other-window, in bookmark.el References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.74 > In bookmark-jump-other-window and bookmark-bmenu-other-window we call > switch-to-buffer-other-window. We should use pop-to-buffer, instead. > > With non-nil pop-up-frames, switch-to-buffer-other-window creates a > new frame each time, even if the destination buffer is already showing > in some frame. pop-to-buffer DTRT: it reuses the existing frame. 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. martin From drew.adams@oracle.com Wed Sep 2 07:39:00 2009 Received: (at 4293) by emacsbugs.donarmstrong.com; 2 Sep 2009 14:39:00 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-4.0 required=4.0 tests=AWL,FOURLA,HAS_BUG_NUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from rgminet11.oracle.com (rcsinet11.oracle.com [148.87.113.123]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n82Ecxt8003150 for <4293@emacsbugs.donarmstrong.com>; Wed, 2 Sep 2009 07:39:00 -0700 Received: from rgminet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by rgminet11.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n82EdMmD016857 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 2 Sep 2009 14:39:23 GMT Received: from abhmt004.oracle.com (abhmt004.oracle.com [141.146.116.13]) by rgminet13.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n82Ed8Q5013462; Wed, 2 Sep 2009 14:39:08 GMT Received: from dradamslap1 (/141.144.80.100) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 02 Sep 2009 07:38:49 -0700 From: "Drew Adams" To: "'martin rudalics'" , <4293@debbugs.gnu.org> References: <4A9E41E3.1000201@gmx.at> Subject: RE: bug#4293: 23.1; use pop-to-buffer, not switch...other-window, in bookmark.el Date: Wed, 2 Sep 2009 07:39:10 -0700 Message-ID: <0EDDA64C33FD4884B064564DC880B5F3@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <4A9E41E3.1000201@gmx.at> Thread-Index: AcortCIeO90zzWn/SA6mXmz2MXYwLgAJncVA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Source-IP: abhmt004.oracle.com [141.146.116.13] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090209.4A9E837A.011C:SCFSTAT5015188,ss=1,fgs=0 > > In bookmark-jump-other-window and bookmark-bmenu-other-window we call > > switch-to-buffer-other-window. We should use pop-to-buffer, instead. > > > > With non-nil pop-up-frames, switch-to-buffer-other-window creates a > > new frame each time, even if the destination buffer is > > already showing in some frame. pop-to-buffer DTRT: it reuses > > the existing frame. > > 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. 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. From rudalics@gmx.at Wed Sep 2 08:47:30 2009 Received: (at 4293) by emacsbugs.donarmstrong.com; 2 Sep 2009 15:47:30 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-4.3 required=4.0 tests=AWL,FOURLA,HAS_BUG_NUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 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 n82FlS6V016762 for <4293@emacsbugs.donarmstrong.com>; Wed, 2 Sep 2009 08:47:30 -0700 Received: (qmail invoked by alias); 02 Sep 2009 15:47:21 -0000 Received: from 62-47-53-203.adsl.highway.telekom.at (EHLO [62.47.53.203]) [62.47.53.203] by mail.gmx.net (mp011) with SMTP; 02 Sep 2009 17:47:21 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX19gZ+k2vBNgZ1HK0c68TQYwi3d7UMrE5O7K7un6QV oKw5ILDKoSDbwP Message-ID: <4A9E9387.5010106@gmx.at> Date: Wed, 02 Sep 2009 17:47:19 +0200 From: martin rudalics User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Drew Adams CC: 4293@debbugs.gnu.org Subject: Re: bug#4293: 23.1; use pop-to-buffer, not switch...other-window, in bookmark.el References: <4A9E41E3.1000201@gmx.at> <0EDDA64C33FD4884B064564DC880B5F3@us.oracle.com> In-Reply-To: <0EDDA64C33FD4884B064564DC880B5F3@us.oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.73 >> 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". > 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. Please tell which specific detail of `switch-to-buffer-other-window' you dislike in the present use case. 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. martin From drew.adams@oracle.com Wed Sep 2 09:16:46 2009 Received: (at 4293) by emacsbugs.donarmstrong.com; 2 Sep 2009 16:16:47 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-4.0 required=4.0 tests=AWL,FOURLA,HAS_BUG_NUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 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 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 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 Received: from dradamslap1 (/130.35.178.194) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 02 Sep 2009 09:16:34 -0700 From: "Drew Adams" To: "'martin rudalics'" Cc: <4293@debbugs.gnu.org> References: <4A9E41E3.1000201@gmx.at> <0EDDA64C33FD4884B064564DC880B5F3@us.oracle.com> <4A9E9387.5010106@gmx.at> Subject: RE: 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> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 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 > >> 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. From rudalics@gmx.at Wed Sep 2 09:46:06 2009 Received: (at 4293) by emacsbugs.donarmstrong.com; 2 Sep 2009 16:46:06 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-4.3 required=4.0 tests=AWL,FOURLA,HAS_BUG_NUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 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 Received: (qmail invoked by alias); 02 Sep 2009 16:45:58 -0000 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 Message-ID: <4A9EA144.80708@gmx.at> Date: Wed, 02 Sep 2009 18:45:56 +0200 From: martin rudalics User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Drew Adams CC: 4293@debbugs.gnu.org Subject: Re: bug#4293: 23.1; use pop-to-buffer, not switch...other-window, in bookmark.el References: <4A9E41E3.1000201@gmx.at> <0EDDA64C33FD4884B064564DC880B5F3@us.oracle.com> <4A9E9387.5010106@gmx.at> <8BA10FD9BFF44AD3BDCE2184D7577DF9@us.oracle.com> In-Reply-To: <8BA10FD9BFF44AD3BDCE2184D7577DF9@us.oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.65 > 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 From drew.adams@oracle.com Wed Sep 2 10:56:19 2009 Received: (at 4293) by emacsbugs.donarmstrong.com; 2 Sep 2009 17:56:19 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-4.0 required=4.0 tests=AWL,HAS_BUG_NUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from rgminet12.oracle.com (rcsinet12.oracle.com [148.87.113.124]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n82HuIUI009660 for <4293@emacsbugs.donarmstrong.com>; Wed, 2 Sep 2009 10:56:19 -0700 Received: from rgminet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by rgminet12.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n82Hu0dV021758 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 2 Sep 2009 17:56:01 GMT Received: from abhmt002.oracle.com (abhmt002.oracle.com [141.146.116.11]) by rgminet13.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n82HuQ6b002082; Wed, 2 Sep 2009 17:56:27 GMT Received: from dradamslap1 (/130.35.178.194) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 02 Sep 2009 10:56:08 -0700 From: "Drew Adams" To: "'martin rudalics'" Cc: <4293@debbugs.gnu.org> References: <4A9E41E3.1000201@gmx.at> <0EDDA64C33FD4884B064564DC880B5F3@us.oracle.com> <4A9E9387.5010106@gmx.at> <8BA10FD9BFF44AD3BDCE2184D7577DF9@us.oracle.com> <4A9EA144.80708@gmx.at> Subject: RE: bug#4293: 23.1; use pop-to-buffer, not switch...other-window, in bookmark.el Date: Wed, 2 Sep 2009 10:56:08 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <4A9EA144.80708@gmx.at> Thread-Index: Acor7OUiSF6lGGLoQDCGMbxA98wZAAACWL5w X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Source-IP: abhmt002.oracle.com [141.146.116.11] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090207.4A9EB1B9.0002:SCFSTAT5015188,ss=1,fgs=0 > I can't reproduce it. I can't reproduce it now either. ;-) I don't have the time now to try to get back to where/how it happened. Perhaps something changed in this regard between Emacs 22 and 23? Dunno. Sorry for the noise. If I get some more info about this, I'll file a new bug. Thx. From monnier@iro.umontreal.ca Wed Sep 2 14:22:48 2009 Received: (at 4293) by emacsbugs.donarmstrong.com; 2 Sep 2009 21:22:48 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-2.8 required=4.0 tests=AWL,HAS_BUG_NUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from ironport2-out.teksavvy.com (ironport2-out.teksavvy.com [206.248.154.182]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n82LMk7S018315 for <4293@emacsbugs.donarmstrong.com>; Wed, 2 Sep 2009 14:22:47 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArMEABN/nkpFpYuS/2dsb2JhbACBU9sWhBsFh3A X-IronPort-AV: E=Sophos;i="4.44,320,1249272000"; d="scan'208";a="45046419" Received: from 69-165-139-146.dsl.teksavvy.com (HELO pastel.home) ([69.165.139.146]) by ironport2-out.teksavvy.com with ESMTP; 02 Sep 2009 17:21:29 -0400 Received: by pastel.home (Postfix, from userid 20848) id 43E227F45; Wed, 2 Sep 2009 17:22:40 -0400 (EDT) From: Stefan Monnier To: Drew Adams Cc: 4293@debbugs.gnu.org, "'martin rudalics'" Subject: Re: bug#4293: 23.1; use pop-to-buffer, not switch...other-window, in bookmark.el Message-ID: References: <4A9E41E3.1000201@gmx.at> <0EDDA64C33FD4884B064564DC880B5F3@us.oracle.com> Date: Wed, 02 Sep 2009 17:22:40 -0400 In-Reply-To: <0EDDA64C33FD4884B064564DC880B5F3@us.oracle.com> (Drew Adams's message of "Wed, 2 Sep 2009 07:39:10 -0700") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii > Users should not have to customize a global variable, to prevent a new frame > from being used in particular places like this. I believe you are a bit confused about what's happening. Sticking to the fact, your bug report complains that bookmark created a new frame when it could have reused another one, right? AFAICT, switch-to-buffer-other-window and pop-to-buffer should behave identically in this respect, to the extend that you pass a non-nil `other-window' argument to pop-to-buffer. So most likely the problem is in pop-to-buffer (which is used by switch-to-buffer-other-window). > 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. Actually, no: switch-to-buffer-other-window is just a wrapper around pop-to-buffer, and doesn't bother me at all. It's switch-to-buffer that's a problem when called from Lisp. Stefan From drew.adams@oracle.com Wed Sep 2 14:29:59 2009 Received: (at 4293) by emacsbugs.donarmstrong.com; 2 Sep 2009 21:29:59 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-4.0 required=4.0 tests=AWL,HAS_BUG_NUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from rgminet12.oracle.com (rcsinet12.oracle.com [148.87.113.124]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n82LTwHx019390 for <4293@emacsbugs.donarmstrong.com>; Wed, 2 Sep 2009 14:29:59 -0700 Received: from rgminet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by rgminet12.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n82LTet1029921 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 2 Sep 2009 21:29:42 GMT Received: from abhmt005.oracle.com (abhmt005.oracle.com [141.146.116.14]) by rgminet15.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n82LTnmO014938; Wed, 2 Sep 2009 21:29:49 GMT Received: from dradamslap1 (/130.35.178.194) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 02 Sep 2009 14:29:48 -0700 From: "Drew Adams" To: "'Stefan Monnier'" Cc: <4293@debbugs.gnu.org>, "'martin rudalics'" References: <4A9E41E3.1000201@gmx.at><0EDDA64C33FD4884B064564DC880B5F3@us.oracle.com> Subject: RE: bug#4293: 23.1; use pop-to-buffer, not switch...other-window, in bookmark.el Date: Wed, 2 Sep 2009 14:29:47 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: AcosE6uxs5T00P7NTvqeTcqFjO0i8QAAMGUw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Source-IP: abhmt005.oracle.com [141.146.116.14] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090203.4A9EE3CD.012D:SCFSTAT5015188,ss=1,fgs=0 > Actually, no: switch-to-buffer-other-window is just a wrapper around > pop-to-buffer, and doesn't bother me at all. > It's switch-to-buffer that's a problem when called from Lisp. My bad. And I cannot reproduce the problem I saw now. From kfogel@red-bean.com Sun Oct 4 19:01:45 2009 Received: (at 4293-close) by emacsbugs.donarmstrong.com; 5 Oct 2009 02:01:45 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=0.1 required=4.0 tests=AWL,FOURLA autolearn=no version=3.2.5-bugs.debian.org_2005_01_02 Received: from sanpietro.red-bean.com (Debian-exim@sanpietro.red-bean.com [66.146.206.141]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n9521iVx011735 for <4293-close@emacsbugs.donarmstrong.com>; Sun, 4 Oct 2009 19:01:45 -0700 Received: from localhost ([127.0.0.1]:34850 helo=floss ident=kfogel) by sanpietro.red-bean.com with esmtp (Exim 4.69) (envelope-from ) id 1MuctT-00088y-UW for 4293-close@emacsbugs.donarmstrong.com; Sun, 04 Oct 2009 21:01:44 -0500 From: Karl Fogel To: 4293-close@debbugs.gnu.org Subject: Re: use pop-to-buffer, not switch...other-window, in bookmark.el Reply-To: Karl Fogel Date: Sun, 04 Oct 2009 22:01:43 -0400 Message-ID: <87skdymwe0.fsf@red-bean.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii tags unreproducible -- Closing this as "unreproducible". Or anyway, attempting to close as unreproducible -- our bug tracker is too unusuable for me to be confident of the effects of the commands I'm trying to issue. FWIW, here's a response I typed up before reading the full bug correspondence. It's not relevant anymore, but if the bug ever reappears, it might become relevant to testers: This would change the user-visible behavior. For example, assume you're in a frame with one window, displaying buffer X. In the current code, doing 'M-x bookmark-jump-other-window' and entering bookmark "foo" at the prompt will open a new window displaying buffer Y (assuming 'foo' points to a location in Y). In other words, the frame will be divided into two windows. But if we replace "switch-to-buffer-other-window" with "pop-to-buffer" in `bookmark-jump-other-window', then the new behavior will be to *replace* the current whole-frame window displaying X with a new whole-frame window displaying Y. That is not the desired behavior. From unknown Tue Jun 17 21:52:33 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Mon, 02 Nov 2009 15:24:14 +0000 User-Agent: Fakemail v42.6.9 # A New Hope # A long time ago, in a galaxy far, far away # something happened. # # Magically this resulted in the following # action being taken, but this fake control # message doesn't tell you why it happened # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator