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:[EMAIL PROTECTED]
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);
}
_______________________________________________
Emacs-devel mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/emacs-devel
