GNU bug report logs - #12648
24.2.50; display-buffer switches to another frame

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 12648 in the body.
You can then email your comments to 12648 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.2.50; display-buffer switches to another frame
Date: Sun, 14 Oct 2012 18:49:44 +0200

This bug report will be sent to the Bug-GNU-Emacs mailing list
and the GNU bug tracker at debbugs.gnu.org.  Please check that
the From: line contains a valid email address.  After a delay of up
to one day, you should receive an acknowledgment at that address.

Please write in English if possible, as the Emacs maintainers
usually do not have translators for other languages.

Please describe exactly what actions triggered the bug, and
the precise symptoms of the bug.  If you can, give a recipe
starting from `emacs -Q':

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

If Emacs crashed, and you have the Emacs process in the gdb debugger,
please include the output from the following gdb commands:
    `bt full' and `xbacktrace'.
For information about debugging Emacs, please read the file
d:/gnu/bzr/emacs/trunk/etc/DEBUG.


In GNU Emacs 24.2.50.1 (i386-mingw-nt5.1.2600)
 of 2012-10-14 on HOME-C4E4A596F7
Bzr revision: 110541 monnier <at> iro.umontreal.ca-20121014014248-jy0lxhbhkiihxjy0
Windowing system distributor `Microsoft Corp.', version 5.1.2600
Configured using:
 `configure --with-gcc (3.4) --no-opt --enable-checking --cflags
 -Id:/usr/include/libxml2 -DGLYPH_DEBUG=1'

Important settings:
  value of $LANG: ENU
  locale-coding-system: cp1255
  default enable-multibyte-characters: t

Major mode: Fundamental

Minor modes in effect:
  tooltip-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
C-x b f o o <return> C-x 5 b b a r <return> M-: ( d 
i s p l a y - b u f f e r SPC " f o o " S-SPC ' <backspace> 
n i l SPC ' v i s i b l e ) <return> <switch-frame> 
<help-echo> M-x r e p o r t - e m <tab> <return>

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
#<window 3 on foo>

Load-path shadows:
None found.

Features:
(shadow sort gnus-util mail-extr emacsbug message format-spec rfc822 mml
easymenu mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231
mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums
mm-util mail-prsvr mail-utils time-date tooltip ediff-hook vc-hooks
lisp-float-type mwheel dos-w32 ls-lisp w32-common-fns disp-table w32-win
w32-vars tool-bar dnd fontset image regexp-opt fringe tabulated-list
newcomment lisp-mode register page menu-bar rfn-eshadow timer select
scroll-bar mouse jit-lock font-lock syntax facemenu font-core frame cham
georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao
korean japanese hebrew greek romanian slovak czech european ethiopic
indian cyrillic chinese case-table epa-hook jka-cmpr-hook help simple
abbrev minibuffer button faces cus-face macroexp files text-properties
overlay sha1 md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote make-network-process w32 multi-tty
emacs)

Message #8 received at 12648 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 12648 <at> debbugs.gnu.org
Subject: Re: bug#12648: 24.2.50; display-buffer switches to another frame
Date: Sun, 14 Oct 2012 20:33:52 +0200

>  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

Message #11 received at 12648 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 12648 <at> debbugs.gnu.org
Subject: Re: 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 <at> gmx.at>
> CC: 12648 <at> 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.

Message #14 received at 12648 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 12648 <at> debbugs.gnu.org
Subject: Re: bug#12648: 24.2.50; display-buffer switches to another frame
Date: Mon, 15 Oct 2012 14:52:44 +0200

>>  >  M-: (display-buffer "foo" nil 'visible) RET
[...]
>>  > 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?

I think so.

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

Well, if you call `display-buffer' with the FRAME argument 'visible
you're explicitly asking for such behavior.

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

We have a choice between Scylla and Charybdis.  People complained that
making a new frame select the window and reusing an existing frame not
select the window would break their typing habits ...

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

IIUC that's what Chong's `inhibit-switch-frame' alist entry is meant
for.  I haven't tried it yet, though.

martin

Message #17 received at 12648 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 12648 <at> debbugs.gnu.org
Subject: Re: bug#12648: 24.2.50; display-buffer switches to another frame
Date: Mon, 15 Oct 2012 19:26:29 +0200

> Date: Mon, 15 Oct 2012 14:52:44 +0200
> From: martin rudalics <rudalics <at> gmx.at>
> CC: 12648 <at> debbugs.gnu.org
> 
>  > I think this is different: setting pop-up-frames non-nil expresses a
>  > wish to see certain behavior that the default shouldn't have.
> 
> Well, if you call `display-buffer' with the FRAME argument 'visible
> you're explicitly asking for such behavior.

Fair enough.

>  > Yes, but is the current behavior useful as it is?
> 
> We have a choice between Scylla and Charybdis.  People complained that
> making a new frame select the window and reusing an existing frame not
> select the window would break their typing habits ...
> 
>  > 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.
> 
> IIUC that's what Chong's `inhibit-switch-frame' alist entry is meant
> for.  I haven't tried it yet, though.

Is that supposed to fix the source-in-other-frame case without harming
the source-in-other-window case (which works correctly with the
current code in gud.el)?  If so, then all we need is to change gud.el
to use that entry.  If some people want the current behavior with
'visible, then so be it; I only want to fix GUD, where I don't believe
anyone would want it.

Thanks.

Message #20 received at 12648 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 12648 <at> debbugs.gnu.org
Subject: Re: bug#12648: 24.2.50; display-buffer switches to another frame
Date: Tue, 16 Oct 2012 11:39:31 +0200

>> IIUC that's what Chong's `inhibit-switch-frame' alist entry is meant
>> for.  I haven't tried it yet, though.
>
> Is that supposed to fix the source-in-other-frame case without harming
> the source-in-other-window case (which works correctly with the
> current code in gud.el)?  If so, then all we need is to change gud.el
> to use that entry.  If some people want the current behavior with
> 'visible, then so be it; I only want to fix GUD, where I don't believe
> anyone would want it.

IIUC a user can either set

 `reusable-frames' -- Value specifies frame(s) to search for a
                      window that already displays the buffer.
                      See `display-buffer-reuse-window'.

to nil so the buffer will get displayed on the selected frame even if it
is displayed somewhere elese, or set

 `inhibit-switch-frame' -- A non-nil value prevents any other
                           frame from being raised or selected,
                           even if the window is displayed there.

to t.  The semantics of the latter is not very clear to me because with
most window managers Emacs cannot prevent a new frame from being raised
and selected (at least that's what I've been told repeatedly).

martin

Message #23 received at 12648 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: martin rudalics <rudalics <at> gmx.at>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 12648 <at> debbugs.gnu.org
Subject: Re: bug#12648: 24.2.50; display-buffer switches to another frame
Date: Tue, 16 Oct 2012 09:27:01 -0400

>  `inhibit-switch-frame' -- A non-nil value prevents any other
>                            frame from being raised or selected,
>                            even if the window is displayed there.
> to t.  The semantics of the latter is not very clear to me because
> with most window managers Emacs cannot prevent a new frame from being
> raised and selected (at least that's what I've been told repeatedly).

I'm not sure what is its semantics either, but the problem you're
referring to is specifically when *creating* a new frame, so it
basically means that inhibit-switch-frame can only work reliably if it
prevents creation of new frames.  But it might still make a difference
when using an existing frame by preventing that we raise that frame.
Not sure if it will also repvent it from being de-iconified (which
would again risk raising it outside of our control).


        Stefan

Message #26 received at 12648 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 12648 <at> debbugs.gnu.org
Subject: Re: bug#12648: 24.2.50; display-buffer switches to another frame
Date: Wed, 17 Oct 2012 11:37:59 +0200

> I'm not sure what is its semantics either, but the problem you're
> referring to is specifically when *creating* a new frame, so it
> basically means that inhibit-switch-frame can only work reliably if it
> prevents creation of new frames.  But it might still make a difference
> when using an existing frame by preventing that we raise that frame.
> Not sure if it will also repvent it from being de-iconified (which
> would again risk raising it outside of our control).

Looks like a problem with reconciling conflicting values in the
`inhibit-switch-frame' (t) and `reusable-frames' (0 or t) entries.

martin

Message #29 received at 12648 <at> debbugs.gnu.org (full text, mbox):

From: Chong Yidong <cyd <at> gnu.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: martin rudalics <rudalics <at> gmx.at>, 12648 <at> debbugs.gnu.org
Subject: Re: bug#12648: 24.2.50; display-buffer switches to another frame
Date: Fri, 19 Oct 2012 03:46:20 +0800

Eli Zaretskii <eliz <at> gnu.org> writes:

>> Well, if you call `display-buffer' with the FRAME argument 'visible
>> you're explicitly asking for such behavior.
>
> Fair enough.

I think the trouble is that gud-display-line has no business setting the
FRAME argument.  Fixed in trunk.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.