bug#16767: [External] : bug#16767: 24.3.50; `C-x 5 b' for special-display buffers

[Drew Adams]

1. From the bug report:

  (display-buffer-other-frame "*scratch*"), likewise,
  does not display the buffer in another frame.

From the doc of `display-buffer-other-frame':

 This function attempts to look for a window
 displaying BUFFER, on all the frames on the
 current terminal, skipping the selected window;
                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 if that fails, it pops up a new frame.

That's not what happens.  It's not skipping the
selected frame.  The doc is unequivocal.

2. From the bug report:

  Similarly, (pop-to-buffer "*scratch*" t) does
  not pop to *scratch* in another window.

From the doc of `pop-to-buffer':

 ACTION is t if called interactively with a
 prefix argument, which means to pop to a
 window other than the selected one
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 even if the buffer is already displayed
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 in the selected window.
 ^^^^^^^^^^^^^^^^^^^^^^

That's not what happens.  It's not using a
window other than the selected one, with an
ACTION value of `t' (including interactively
with a prefix arg).  Again, the doc's crystal
clear - no ifs, ands, or buts.

Even if you have two frames with `*scratch*',
and you try `C-u pop-to-buffer *scratch*' in
one of them, the other one is NOT selected.

3. The doc string of `switch-to-buffer-other-frame'
says nothing about not switching to the buffer
in another frame.  It just says, clearly, that
the command switches to the buffer in another
frame - unconditionally.

In the Elisp manual it's even clearer:

 If the specified buffer is already displayed in
 another window, in any frame on the current
 terminal, this switches to that window instead of
 creating a new frame.
 However, the selected window is never used for this.
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

The doc, everywhere, for all 3 of the commands
reported by the bug report, says unequivocally
that in the cases described another window
(in another frame) is used, even if it has to
be created.

Is the doc wrong everywhere?  Do you think the
_intention_ of someone using a `C-x 5' prefix is
ever to NOT use another frame?  IMHO, it's the
implementation that's bugged, not the doc and
not the intention behind `C-x 5'.

And it's not surprising that such a bug could go
unreported for a long time.  I suspect that most
users don't use `other-frame' commands that often.
But some users use them a lot.  Ignoring such use
cases and their users doesn't help.

___

The bug report is one thing.  Things got a bit
turned around by some translating to talking
about the implementation in the thread, I think. ;-)
What matters is the behavior for users.  `C-x 5'
is all about using another frame.  And the doc
of these commands specifies clearly what the
expected and intended behavior is.