GNU bug report logs - #12139
24.1; `occur-edit-mode' is completely broken if `pop-up-frames'=t

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 12139 in the body.
You can then email your comments to 12139 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: "Drew Adams" <drew.adams <at> oracle.com>
To: <bug-gnu-emacs <at> gnu.org>
Subject: 24.1; `occur-edit-mode' is completely broken if `pop-up-frames'=t
Date: Sat, 4 Aug 2012 13:52:38 -0700

emacs -Q
 
(setq pop-up-frames t)
 
In some buffer, M-x occur, then `e' to enter `occur-edit-mode'.
 
Type a character on the occur buffer.  The frame of the buffer that was
searched is brought to the foreground, obscuring the occur buffer.
What's more, the searched buffer's frame receives the input focus.
 
In sum, you cannot edit the occur buffer at all, because all input takes
place in the searched buffer, and its frame is popped up, in front, each
time you make any change in the occur buffer.
 
This bug is a POSTER CHILD for Emacs Dev's introducing a feature without
ever testing it with a non-nil `pop-up-frames' scenario (or the
equivalent).

In GNU Emacs 24.1.1 (i386-mingw-nt5.1.2600)
 of 2012-06-10 on MARVIN
Windowing system distributor `Microsoft Corp.', version 5.1.2600
Configured using:
 `configure --with-gcc (4.6) --cflags
 -ID:/devel/emacs/libs/libXpm-3.5.8/include
 -ID:/devel/emacs/libs/libXpm-3.5.8/src
 -ID:/devel/emacs/libs/libpng-dev_1.4.3-1/include
 -ID:/devel/emacs/libs/zlib-dev_1.2.5-2/include
 -ID:/devel/emacs/libs/giflib-4.1.4-1/include
 -ID:/devel/emacs/libs/jpeg-6b-4/include
 -ID:/devel/emacs/libs/tiff-3.8.2-1/include
 -ID:/devel/emacs/libs/gnutls-3.0.9/include'
 

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

From: Chong Yidong <cyd <at> gnu.org>
To: "Drew Adams" <drew.adams <at> oracle.com>
Cc: 12139 <at> debbugs.gnu.org
Subject: Re: bug#12139: 24.1;
	`occur-edit-mode' is completely broken if `pop-up-frames'=t
Date: Mon, 06 Aug 2012 12:18:37 +0800

"Drew Adams" <drew.adams <at> oracle.com> writes:

> emacs -Q
> (setq pop-up-frames t)
> In some buffer, M-x occur, then `e' to enter `occur-edit-mode'.
>  
> Type a character on the occur buffer.  The frame of the buffer that was
> searched is brought to the foreground, obscuring the occur buffer.
> What's more, the searched buffer's frame receives the input focus.

It's a long-standing issue with display-buffer.  The docstring of
display-buffer says

   Display BUFFER-OR-NAME in some window, without selecting it.

But when pop-up-frames is non-nil, display-buffer does explicitly select
the window, via raising its frame.  One could argue that this is
desirable because the frame that is being re-used might be obscured or
out of sight, but it interferes with Lisp callers which want to display
stuff in another window without losing focus from the current one (which
is the main role of display-buffer).

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

From: Chong Yidong <cyd <at> gnu.org>
To: "Drew Adams" <drew.adams <at> oracle.com>
Cc: 12139 <at> debbugs.gnu.org
Subject: Re: bug#12139: 24.1;
	`occur-edit-mode' is completely broken if `pop-up-frames'=t
Date: Mon, 06 Aug 2012 13:28:21 +0800

Chong Yidong <cyd <at> gnu.org> writes:

> It's a long-standing issue with display-buffer.  The docstring of
> display-buffer says
>
>    Display BUFFER-OR-NAME in some window, without selecting it.
>
> But when pop-up-frames is non-nil, display-buffer does explicitly select
> the window, via raising its frame.  One could argue that this is
> desirable because the frame that is being re-used might be obscured or
> out of sight, but it interferes with Lisp callers which want to display
> stuff in another window without losing focus from the current one (which
> is the main role of display-buffer).

On reflection, I think this would be a useful application of the new
display action parameter mechanism.  So I introduced a new
`inhibit-switch-frame' action alist entry; callers like occur-edit,
which require keeping focus can supply this parameter, can use this to
tell `display-buffer' to avoid stealing focus away to another frame,
even at the expense of obscuring the displayed window.

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

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'Chong Yidong'" <cyd <at> gnu.org>
Cc: 12139 <at> debbugs.gnu.org
Subject: RE: bug#12139: 24.1;
	`occur-edit-mode' is completely broken if `pop-up-frames'=t
Date: Sun, 5 Aug 2012 23:17:53 -0700

> > It's a long-standing issue with display-buffer.  The docstring of
> > display-buffer says
> >
> >    Display BUFFER-OR-NAME in some window, without selecting it.
> >
> > But when pop-up-frames is non-nil, display-buffer does 
> > explicitly select the window, via raising its frame.  One could
> > argue that this is desirable because the frame that is being
> > re-used might be obscured or out of sight, but it interferes
> > with Lisp callers which want to display stuff in another window
> > without losing focus from the current one (which is the main
> > role of display-buffer).
> 
> On reflection, I think this would be a useful application of the new
> display action parameter mechanism.  So I introduced a new
> `inhibit-switch-frame' action alist entry; callers like occur-edit,
> which require keeping focus can supply this parameter, can use this to
> tell `display-buffer' to avoid stealing focus away to another frame,
> even at the expense of obscuring the displayed window.

Thanks for the prompt fix.  When I get an MS Windows binary I will check whether
it takes care of things also when a standalone minibuffer frame is used on
Windows.  Thx.

Previous Next

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