bug#12648: 24.2.50; display-buffer switches to another frame

[martin rudalics]

>  emacs -Q
>  C-x b foo
>  C-x 5 b bar
>
> Now you have 2 frames, one displays the buffer "foo", the other
> displays the buffer "bar" and is the selected frame.
>
>  M-: (display-buffer "foo" nil 'visible) RET
>
> This quite unexpectedly selects the frame which displays "foo".  But
> display-buffer is not supposed to select the window where it displays
> the buffer.

Unless it appears on another frame.  If with emacs -Q you do

(let ((pop-up-frames t))
  (display-buffer (get-buffer-create "baz")))

that buffer is shown on a new frame and its window is selected.

> And indeed, if the same experiment is repeated when the
> same frame displays "foo" and "bar" in 2 different windows, the window
> that shows "bar" being the selected one, display-buffer does not
> select the other window, as expected.
>
> This is an annoyance when you use GUD with the GDB interaction buffer
> on one frame and the source on another.  Each command that moves
> through the program, such as 'n', 's', etc., switches to the source
> frame, which is inconvenient.  See
>
>   http://lists.gnu.org/archive/html/help-gnu-emacs/2012-10/msg00188.html
>
> for the original complaint.

Maybe we should provide an alist entry like select-frame for this.  If
the buffer already appears in another frame, we would select the frame
only if the entry is set.  If a new frame is created, we could try to
not select it if the entry is not set and the window manager supports
creating a frame and not selecting it.

martin