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

[martin rudalics]

> 1. From the bug report:
>
>    (display-buffer-other-frame "*scratch*"), likewise,
>    does not display the buffer in another frame.

It does so by default.  You are using an option whose purpose is to
override the default behavior.

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

The doc specifies the default behavior.  You are using an option that
overrides the default behavior.

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

The doc specifies the default behavior.  You are using an option that
overrides the default behavior.

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

I have no idea what `C-u pop-to-buffer *scratch*' means.  But if, with
emacs -Q, I evaluate

(pop-to-buffer "*scratch*" t)

it will pop to *scratch* in another window.

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

Because you are using an option that overrides the default behavior.

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

Unless you are using an option that overrides the default behavior.

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

You are using an obsolete option whose purpose is to override the
documented behavior so you are getting what you asked for.  Please stop
calling that a bug if you want that your arguments are taken seriously.

Your posting is a strong argument for removing `special-display-regexps'
and its ilk ASAP.

martin