bug#17719: 24.4.50; REGRESSION: `switch-to-buffer-other-frame' does not use other frame

[Drew Adams <drew.adams@oracle.com>]

> > This regression seems to have been introduced in Emacs 23.  There is no
> > such problem in Emacs 22.3 and prior.
> > emacs -Q
> > Visit some file, say foo.el, alone in the frame.
> > C-x 2 C-x 3 ; show the buffer in 3 windows
> > C-x 5 b foo.el ; type the same buffer name, explicitly
> > One of the other windows on the same frame is selected.
> 
> That's the intended behavior, AFAIK.  The behavior changed in one of
> the last versions (not sure exactly which one, but could very well be
> Emacs 23).

Ah yes.  I remember now.  This is not the first bug report about this.
Mark Kennedy filed a report entitled "switch-to-buffer-other-frame
fails to pop-up window" on Dec 3, 2007 (before we used the bug tracker,
I believe).  I even said then that I liked the new behavior (!).

However, I wonder now if that shouldn't be the behavior just for
`C-x 4 b' with non-nil `pop-up-frames', and not for `C-x 5 b'.
Just a thought.  The doc of `pop-up-frames' used to say that it: 

 looks for an existing window
 already displaying the desired buffer, on any visible frame.  If
 it finds one, it returns that window.  Otherwise it makes a new
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 frame.

(Martin's emphasis, from the cited thread.)  IOW, it was documented
as not necessarily using another frame.  The combination of non-nil
`pop-up-frames' with `switch-to-buffer-other-window' would then not
always impose using a separate frame.  (However, the doc of `p-u-f'
has changed to say now that it always uses a separate frame (for
graphic displays).)

Interactively, a user can use `C-x 5 2' to get the desired new-frame
behavior (but that means s?he needs to know about the exceptional
case and remember another key sequence to cover it).  And if s?he
wants to see similar names of other buffers before choosing, then
s?he needs to use first `C-x 5 b' (or similar) to see the names,
then `C-g', then `C-x 5 2' if the one s?he wants is in fact the
current buffer (e.g., after verifying that what s?he wants is not
some other buffer with a similar name).

Admittedly, those are only minor inconveniences.

In any case, non-interactively things are not so simple.
The circumstance leading to the exceptional behavior is somewhat
complicated:

1. Current buffer is in more than one window of the selected frame.
2. Current buffer is not in any other frame.

If either (1) or (2) is not true then the a new frame is created
and selected for the current buffer.  IOW, this special case means
special-casing one's code, if you want it to switch to an arbitrary
buffer (e.g., a BUFFER arg) in another frame (always).

So regardless of whether we make a change for interactive use,
I wonder if non-interactive (switch-to-buffer-other-frame BUFFER)
shouldn't always create a new frame for BUFFER when it is not
already shown in another frame, even when BUFFER is the current
buffer.

Finally, even if you decide not to change the current behavior,
it should be documented.  Anyone reading the doc will expect that
(switch-to-buffer-other-frame BUFFER) always, not just sometimes,
selects the BUFFER in another frame, and that is not the case.
For the current buffer, it is sometimes the case and sometimes
not the case.