completing-read (and M-x) with pop-up-frames non-nil changes frame focus

completing-read (and M-x) with pop-up-frames non-nil changes frame focus

[Drew Adams]

emacs -q
M-x set-variable pop-up-frames t
M-x complet TAB

This opens a new frame for buffer *Completions*. At least in Windows, the
new frame is selected. The frame focus for typing key sequences thus
switches to the *Completions* frame, but the minibuffer of the original
frame is still waiting for input. So, you cannot continue to type, to
disambiguate the command you want.

You can of course navigate to the command you want in *Completions* and hit
`RET' or click it with the mouse, but the minibuffer completion behavior is
completely lost - to regain it, you need to select the original frame again.

Is this a bug? I suspect, unfortunately, that the answer will be "no, that's
by design". My question then is, how can I prevent the frame focus switch to
*Completions* when I call `completing-read' or access it implicitly, via
`M-x'?

In my own, custom setup, I don't have this problem, because I have dedicated
frames for *Customize* and the minibuffer, and I use a special-display
function to display *Customize*. That function explicitly redirects the
focus from the *Customize* frame back to the minibuffer frame.

However, I want to write some code that others can use, and they will not
necessarily have a similar setup. I want users to be able to continue to
input in the original frame's minibuffer, without having to first reselect
the original frame.

Advice?


In GNU Emacs 22.0.50.1 (i386-mingw-nt5.1.2600)
 of 2005-06-26 on NONIQPC
X server distributor `Microsoft Corp.', version 5.1.2600
configured using `configure --with-gcc
(3.3) --cflags -I../../jpeg-6b-3/include -I../../libpng-1.2.8/include -I../.
./tiff-3.6.1-2/include -I../../xpm-nox-4.2.0/include -I../../zlib-1.2.2/incl
ude'

Re: completing-read (and M-x) with pop-up-frames non-nil changes frame focus

[Stefan Monnier]

> emacs -q
> M-x set-variable pop-up-frames t
> M-x complet TAB

> This opens a new frame for buffer *Completions*. At least in Windows, the
> new frame is selected. The frame focus for typing key sequences thus
> switches to the *Completions* frame, but the minibuffer of the original
> frame is still waiting for input. So, you cannot continue to type, to
> disambiguate the command you want.

Maybe this is related to the following comment in the docstring of
pop-up-frame-function:

   This function itself does not make the new frame the selected frame.
   The previously selected frame remains selected.  However, the
   window system may select the new frame for its own reasons, for
   instance if the frame appears under the mouse pointer and your
   setup is for focus to follow the pointer.

So maybe Fdisplay_buffer should protect against it with something like the
patch below.  Does it help?


        Stefan


--- orig/src/window.c
+++ mod/src/window.c
@@ -3493,7 +3493,10 @@
      we need to create a new frame.  */
   if (pop_up_frames || last_nonminibuf_frame == 0)
     {
+      Lisp_Object w = Fselected_window ();
       window = Fframe_selected_window (call0 (Vpop_up_frame_function));
+      if (Fwindow_live_p w)
+	Fselect_window (w, Qt);
       Fset_window_buffer (window, buffer, Qnil);
       Fset_window_dedicated_p (window, intern ("soft"));
       return display_buffer_1 (window);

Re: completing-read (and M-x) with pop-up-frames non-nil changes frame focus

[Stefan Monnier]

> So maybe Fdisplay_buffer should protect against it with something like the
> patch below.  Does it help?

Sorry about the botched patch.  Try this one instead,


        Stefan


--- window.c	13 jui 2005 13:58:39 -0400	1.512
+++ window.c	15 jui 2005 03:30:07 -0400	
@@ -3475,7 +3475,13 @@
      we need to create a new frame.  */
   if (pop_up_frames || last_nonminibuf_frame == 0)
     {
+      Lisp_Object w = Fselected_window ();
+      struct gcpro gcpro1;
+      GCPRO1 (w);
       window = Fframe_selected_window (call0 (Vpop_up_frame_function));
+      if (Fwindow_live_p (w))
+	Fselect_window (w, Qt);
+      UNGCPRO;
       Fset_window_buffer (window, buffer, Qnil);
       return display_buffer_1 (window);
     }

RE: completing-read (and M-x) with pop-up-frames non-nil changes frame focus

[Drew Adams]

    > emacs -q
    > M-x set-variable pop-up-frames t
    > M-x complet TAB

    > This opens a new frame for buffer *Completions*. At least in
    Windows, the
    > new frame is selected. The frame focus for typing key sequences thus
    > switches to the *Completions* frame, but the minibuffer of
    the original
    > frame is still waiting for input. So, you cannot continue to type, to
    > disambiguate the command you want.

    Maybe this is related to the following comment in the docstring of
    pop-up-frame-function:

       This function itself does not make the new frame the selected frame.
       The previously selected frame remains selected.  However, the
       window system may select the new frame for its own reasons, for
       instance if the frame appears under the mouse pointer and your
       setup is for focus to follow the pointer.

    So maybe Fdisplay_buffer should protect against it with
    something like the
    patch below.  Does it help?

  Sorry about the botched patch.  Try this one instead,

Thanks for considering this a bug - I wasn't sure it would be looked at that
way.

I can't build from C sources and test this myself, but I'll take your word
for it that it's fixed. If someone else happens to do a Windows build,
perhaps s?he could confirm.  Thanks.

Re: completing-read (and M-x) with pop-up-frames non-nil changes frame focus

[Stefan Monnier]

> I can't build from C sources and test this myself, but I'll take your word
> for it that it's fixed. If someone else happens to do a Windows build,
> perhaps s?he could confirm.  Thanks.

I'm far from sure it'll fix the bug and if it doesn't, I'd rather not
install it, so please have someone try it before I install it,


        Stefan

RE: completing-read (and M-x) with pop-up-frames non-nil changes frame focus

[Drew Adams]

    I'm far from sure it'll fix the bug and if it doesn't, I'd rather not
    install it, so please have someone try it before I install it,
    
I agree, but I don't have a way to check it myself.  

Re: completing-read (and M-x) with pop-up-frames non-nil changes frame focus

[Richard M. Stallman]

    This opens a new frame for buffer *Completions*. At least in Windows, the
    new frame is selected. The frame focus for typing key sequences thus
    switches to the *Completions* frame, but the minibuffer of the original
    frame is still waiting for input. So, you cannot continue to type, to
    disambiguate the command you want.

You would have to move the mouse to the other frame, I guess.
Is that what you're complaining about, or is it some other behavior?
Is it a Windows-only behavior?

RE: completing-read (and M-x) with pop-up-frames non-nil changes framefocus

[Drew Adams]

        This opens a new frame for buffer *Completions*. At least
        in Windows, the
        new frame is selected. The frame focus for typing key sequences thus
        switches to the *Completions* frame, but the minibuffer of
        the original
        frame is still waiting for input. So, you cannot continue
        to type, to
        disambiguate the command you want.

    You would have to move the mouse to the other frame, I guess.

On Windows, you have to manually select original the frame (e.g. click the
title bar).

In any case, you should not need to move the mouse or click the original
frame. *Completions* should only be displayed, not selected, whether or not
it is in another frame.

    Is that what you're complaining about, or is it some other behavior?
    Is it a Windows-only behavior?

I don't know if it is Windows-specific.

Stefan sent a C patch to fix this problem last Friday. I cannot check it,
but perhaps someone else can.

Re: completing-read (and M-x) with pop-up-frames non-nil changes framefocus

[Richard M. Stallman]

    On Windows, you have to manually select original the frame (e.g. click the
    title bar).

    In any case, you should not need to move the mouse or click the original
    frame. *Completions* should only be displayed, not selected, whether or not
    it is in another frame.

When focus follows the mouse, it is difficult to avoid selecting it
if it shows up under the mouse.

When the window manager is using click-to-focus, it would be good if
this frame appeared without being selected.  Emacs once tried to
implement this, around 10 years ago, but I think it did not work
right, so it was taken out.

RE: completing-read (and M-x) with pop-up-frames non-nil changesframefocus

[Drew Adams]

        On Windows, you have to manually select original the frame
        (e.g. click the title bar).

        In any case, you should not need to move the mouse or click
        the original
        frame. *Completions* should only be displayed, not
        selected, whether or not it is in another frame.

    When focus follows the mouse, it is difficult to avoid selecting it
    if it shows up under the mouse.

I didn't have focus-follows-mouse turned on.

If it were on, and if the new frame did not happen to show up under the
mouse, it would not be selected, right?

    When the window manager is using click-to-focus, it would be good if
    this frame appeared without being selected.

Yes. That's the problem.

    Emacs once tried to
    implement this, around 10 years ago, but I think it did not work
    right, so it was taken out.

I guess you're saying that when a frame is created it is always given the
focus. That's too bad.

Stefan seemed to have a fix for this, at least in this case, but it needs to
be tested on Windows.

Re: completing-read (and M-x) with pop-up-frames non-nil changesframefocus

[Richard M. Stallman]

	When focus follows the mouse, it is difficult to avoid selecting it
	if it shows up under the mouse.

    I didn't have focus-follows-mouse turned on.

    If it were on, and if the new frame did not happen to show up under the
    mouse, it would not be selected, right?

No, that variable is meant to tell Emacs what the window manager does.

    I guess you're saying that when a frame is created it is always given the
    focus. That's too bad.

I am saying that the system decides what frame gets focus.

RE: completing-read (and M-x) with pop-up-frames non-nilchangesframefocus

[Drew Adams]

    	When focus follows the mouse, it is difficult to avoid selecting it
    	if it shows up under the mouse.

        I didn't have focus-follows-mouse turned on.

        If it were on, and if the new frame did not happen to show
        up under the mouse, it would not be selected, right?

    No, that variable is meant to tell Emacs what the window manager does.

My bad. So users must set it, to tell Emacs about the window manager. But
couldn't the default value be defined reasonably for a few common window
managers?

In emacs -q on Windows, its value is t, but Windows requires you to click a
frame to set the focus. Shouldn't the default value be nil on Windows?
Especially since there is only one window-manager for Windows, so it is easy
to test it - just test the OS.

Anyway, this is all unrelated to the problem at hand.

        I guess you're saying that when a frame is created it is
        always given the focus. That's too bad.

    I am saying that the system decides what frame gets focus.

But what about Stefan's patch? It sounded like it might take care of this
annoyance.

The problem arises because one frame's minibuffer is expecting input, while
another frame (*Completions*) gets created and selected (depending on the
window manager). The input dialog gets totally lost (interrupted),
systematically. This is a problem of frame focus. Leaving it the way it is
discourages people from using pop-up-frames = t, because this behavior is so
annoying.

As I said:

 I don't have this problem, because I have dedicated
 frames for *Customize* and the minibuffer, and I use a
 special-display function to display *Customize*.
 That function explicitly redirects the focus from the
 *Customize* frame back to the minibuffer frame.

Couldn't something equivalent be done, in a more basic way, to ensure that
the input focus for *Completions* remains the original minibuffer that
launched it? The way things are now, it's like opening a door and having it
slam shut in your face.

IOW, independently of the window manager and OS behavior, shouldn't the
input focus for *Completions* be the minibuffer that displayed it?

Re: completing-read (and M-x) with pop-up-frames non-nilchangesframefocus

[Richard M. Stallman]

    My bad. So users must set it, to tell Emacs about the window manager. But
    couldn't the default value be defined reasonably for a few common window
    managers?

In most window managers, this behavior is customizable.  And I don't
know if there is even a way to find out which window manager is
running, on most systems.  I don't know if there is a way to find out
what the setting is.

Maybe some X expert could find out to what extent Emacs could
find this out.

    But what about Stefan's patch? It sounded like it might take care of this
    annoyance.

I don't recall what that patch was.

    The problem arises because one frame's minibuffer is expecting input, while
    another frame (*Completions*) gets created and selected (depending on the
    window manager). The input dialog gets totally lost (interrupted),
    systematically.

Why doesn't Emacs move the minibuffer onto the frame that is selected?
I thought there was code to do that.

Re: completing-read (and M-x) with pop-up-frames non-nilchangesframefocus

[Henrik Enberg]

> From: "Richard M. Stallman" <rms@gnu.org>
> Date: Wed, 20 Jul 2005 18:09:09 -0400
> 
>     My bad. So users must set it, to tell Emacs about the window manager. But
>     couldn't the default value be defined reasonably for a few common window
>     managers?
> 
> In most window managers, this behavior is customizable.  And I don't
> know if there is even a way to find out which window manager is
> running, on most systems.  I don't know if there is a way to find out
> what the setting is.
>
> Maybe some X expert could find out to what extent Emacs could
> find this out.

There is no X standard for this, each window manager does it in its own
way.

Re: completing-read (and M-x) with pop-up-frames non-nilchangesframefocus

[Jan D.]

>     My bad. So users must set it, to tell Emacs about the window  
> manager. But
>     couldn't the default value be defined reasonably for a few  
> common window
>     managers?
>
> In most window managers, this behavior is customizable.  And I don't
> know if there is even a way to find out which window manager is
> running, on most systems.  I don't know if there is a way to find out
> what the setting is.

You can check if a window manager is running, but not which.  You can  
not find out which focus model it uses.  Besides, some window  
managers have more than than the two discussed here.  For example,  
sloppy mouse, which is kind of in between mouse and click.

     Jan D.

RE: completing-read (and M-x) with pop-up-framesnon-nilchangesframefocus

[Drew Adams]

        But what about Stefan's patch? It sounded like it might
        take care of this annoyance.

    I don't recall what that patch was.

See below.

        The problem arises because one frame's minibuffer is
        expecting input, while
        another frame (*Completions*) gets created and selected
        (depending on the
        window manager). The input dialog gets totally lost (interrupted),
        systematically.

    Why doesn't Emacs move the minibuffer onto the frame that is selected?
    I thought there was code to do that.

That would be great. But how would that affect a standalone minibuffer (in a
separate frame)? I use that, and I use a dedicated frame for *Completions*
and explicitly redirect its focus to the minibuffer frame. Could something
like that perhaps be done by default when default-frame-alist has minibuffer
property = nil?


Stefan's patch (untested on Windows):

    -----Original Message-----
    From: Stefan Monnier [mailto:monnier@iro.umontreal.ca]
    Sent: Friday, July 15, 2005 12:36 AM
    To: Drew Adams
    Cc: Emacs-Devel
    Subject: Re: completing-read (and M-x) with pop-up-frames non-nil
    changes frame focus


    > So maybe Fdisplay_buffer should protect against it with
    something like the
    > patch below.  Does it help?

    Sorry about the botched patch.  Try this one instead,

            Stefan

    --- window.c	13 jui 2005 13:58:39 -0400	1.512
    +++ window.c	15 jui 2005 03:30:07 -0400
    @@ -3475,7 +3475,13 @@
          we need to create a new frame.  */
       if (pop_up_frames || last_nonminibuf_frame == 0)
         {
    +      Lisp_Object w = Fselected_window ();
    +      struct gcpro gcpro1;
    +      GCPRO1 (w);
           window = Fframe_selected_window (call0 (Vpop_up_frame_function));
    +      if (Fwindow_live_p (w))
    +	Fselect_window (w, Qt);
    +      UNGCPRO;
           Fset_window_buffer (window, buffer, Qnil);
           return display_buffer_1 (window);
         }

Re: completing-read (and M-x) with pop-up-framesnon-nilchangesframefocus

[Richard M. Stallman]

    That would be great. But how would that affect a standalone minibuffer (in a
    separate frame)?

Selecting a frame which uses that standalone minibuffer
would put the active minibuffer there.

	--- window.c	13 jui 2005 13:58:39 -0400	1.512
	+++ window.c	15 jui 2005 03:30:07 -0400
	@@ -3475,7 +3475,13 @@
	      we need to create a new frame.  */
	   if (pop_up_frames || last_nonminibuf_frame == 0)
	     {
	+      Lisp_Object w = Fselected_window ();
	+      struct gcpro gcpro1;
	+      GCPRO1 (w);
	       window = Fframe_selected_window (call0 (Vpop_up_frame_function));
	+      if (Fwindow_live_p (w))
	+	Fselect_window (w, Qt);
	+      UNGCPRO;
	       Fset_window_buffer (window, buffer, Qnil);
	       return display_buffer_1 (window);
	     }

It looks plausible to me.  I would expect it to have
no effect when the mouse position controls window manager focus,
and that is what it should do, but that needs to be tested.
Could someone test that?

Re: completing-read (and M-x) with pop-up-framesnon-nilchangesframefocus

[Stefan Monnier]

> 	--- window.c	13 jui 2005 13:58:39 -0400	1.512
> 	+++ window.c	15 jui 2005 03:30:07 -0400
> 	@@ -3475,7 +3475,13 @@
> 	      we need to create a new frame.  */
> 	   if (pop_up_frames || last_nonminibuf_frame == 0)
> 	     {
> 	+      Lisp_Object w = Fselected_window ();
> 	+      struct gcpro gcpro1;
> 	+      GCPRO1 (w);
> 	       window = Fframe_selected_window (call0 (Vpop_up_frame_function));
> 	+      if (Fwindow_live_p (w))
> 	+	Fselect_window (w, Qt);
> 	+      UNGCPRO;
> 	       Fset_window_buffer (window, buffer, Qnil);
> 	       return display_buffer_1 (window);
> 	     }

> It looks plausible to me.  I would expect it to have
> no effect when the mouse position controls window manager focus,
> and that is what it should do, but that needs to be tested.
> Could someone test that?

I've been using it here on GNU/Linux with a window-manager that does
focus-follows-mouse and haven't noticed any problem with it.
In reality this patch will have no effect whatsoever in most cases because
Vpop_up_frame_function usually doesn't change the selected window, so the
call to Fselect_window is a nop (the body exits early).

But I still have no idea whether it actually fixes the original problem
or not.  Someone will have to check it,


        Stefan