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

[martin rudalics]

> 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