bug#23131: switch-to-buffer-other-frame problem

[jan <rtm443x@googlemail.com>]

Hi Martin,
please see below

On 28/03/2016, martin rudalics <rudalics@gmx.at> wrote:
>  > e.g Start emacs, then drag a file (say sample.txt) onto it. File opens
> fine.
>  >
>  > Type C-x 5 b
>  >
>  > - minibuffer shows
>  > "Switch to buffer in other frame (default *GNU Emacs*):"
>  >
>  > I type "sam" [tab key for completion]
>  >
>  > - minibuffer says
>  > "Switch to buffer in other frame (default *GNU Emacs*): sam[No Match]"
>  >
>  > odd. If I remove the "sam" I just typed then type '?' to show the
>  > buffer list, it opens a 2nd buffer at the bottom and shows
>  >
>  > Possible completions are:
>  > *GNU Emacs*
>  > *Messages*
>  > *scratch*
>  >
>  > which does not show sample.txt, which is definitly there as I can see
>  > it open in the buffer at the top.
>
> If, in this situation, you type C-x b, Emacs won't offer you sample.txt
> as completion either.  Ditto for ‘switch-to-buffer-other-window’.

I'd say that replication of (arguably questionable) behaviour doesn't
justify it.

> It's
> difficult to say what the correct behavior should be.  I never use the
> buffer switching commands, so I have no preference.  But I suppose that
> some people would complain if C-x b offered them the buffer already
> shown in the selected window as possible completion.

Well, Eli Zaretski said of this (I'd emailed him first) "Yes, it's a
feature: Emacs doesn't offer you a buffer that is already displayed in
an existing window.  This was introduced in Emacs 24."

So it is new behaviour.
Therefore: 1) was it introduced deliberately? If so, why? (if the code
was the code made more complex by introducing a special case rather
than simplifiying it, doubly why?)

And: 2) this behaviour is not documented. My understanding is that
documentation omissions are considered bugs.

> So where would you draw the line?

To me it's about interface usability and stability.  Given the answer
to point (1), I'd be in a much better position to know where to draw
the line.

>
> Basically, to switch to a buffer already shown in a window W, I wouldn't
> type C-x b but use C-x o to get there.  To show the buffer shown in W in
> another window on the same frame, I'd type C-x 2 in W.  To show the
> buffer shown in W in a window on another frame, I'd type C-x 5 2 in W.
>
>  > Also, the behaviour is apparently broken if the current buffer/window is
> split:
>  >
>  > a. open sample.txt
>  > b. C-x 2   -- split window in 2, top and bottom
>  > c. C-x 5 b  -- try to get 2nd frame
>  > d. sample.txt   -- type in full filename in minibuffer
>  > e. 2nd frame does *not* appear, cursor jumps to top of split window,
>  > even if was originally in bottom.
>  >
>  > can reproduce?
>
> Why don't you just use C-x 5 2 here?

Heh. I'd forgotten that! Thanks!
But that doesn't change the original point of why the new behaviour.

> Anyway, this happens because of
> the last two forms in
>
> (defvar display-buffer--other-frame-action
>    '((display-buffer-reuse-window
>       display-buffer-pop-up-frame)
>      (reusable-frames . 0)
>      (inhibit-same-window . t))
>
> which OT1H inhibit using the selected window and OTOH, since we have no
> value for ‘reusable-frames’ to exclude the selected frame from the list
> of reusable frames, allows reusing the window on the bottom.
>
> If people think that it's worth fixing this, we would probably have to
> invent a new alist entry like ‘inhibit-same-frame’.  That change might
> be obtrusive though, so I would not ardently recommend it for emacs-25.

I don't know much about emacs internals so I'll buy the point that a
'fix' would be unnecessary work for the dev team for this latter case.

thanks

jan

>
> martin
>
>