GNU bug report logs - #4293
23.1; use pop-to-buffer, not switch...other-window, in bookmark.el

Previous Next

Full log

View this message in rfc822 format

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'martin rudalics'" <rudalics <at> gmx.at>
Cc: <4293 <at> debbugs.gnu.org>
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

>  >> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.