bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Eli Zaretskii
Subject: bug#12648: 24.2.50; display-buffer switches to another frame
Date: Sun, 14 Oct 2012 21:28:59 +0200

> Date: Sun, 14 Oct 2012 20:33:52 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: 12648@debbugs.gnu.org
> 
>  >  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.

Isn't that difference confusing?

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

I think this is different: setting pop-up-frames non-nil expresses a
wish to see certain behavior that the default shouldn't have.

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

Yes, but is the current behavior useful as it is?

If gud.el should call display-buffer in some different way to avoid
selecting the frame with the source, that, too, could be a good
solution.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]