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

[Drew Adams]

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