Bug reports for GNU Emacs, the Swiss army knife of text editors

Drew Adams | 4 Aug 2012 22:52

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

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

(Continue reading)

headers

Chong Yidong | 6 Aug 2012 06:18

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

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

headers

Chong Yidong | 6 Aug 2012 07:28

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

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.

headers

Drew Adams | 6 Aug 2012 08:17

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

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