For quite some time now I sometimes see an annoying problem in the native MS-Windows (a.k.a. NTEmacs) port of the CVS Emacs: commands that create a new frame somehow fail to display the frame. Examples include "C-x b FOO RET", "C-x m" with rmail-mail-new-frame set to non-nil, etc. What happens is that the frame is created (it appears in the output of `frame-list'), it is not (and cannot be) displayed. Instead, the frame that was current becomes unselected (the cursor changes into a hollow block), and that's it. Emacs is not stuck: if I move the mouse out of the Emacs frame and back into it, the frame that was selected before the offending command becomes again selected and everything is hunky-dory (except that there's a frame that I cannot switch to).
This problem happens in about 50% of the attempts to use the commands that create a new frame. I've seen this on two different machines running Windows XP, and in several versions since last October, up to and including the latest binary I have, which was compiled about a month ago (I didn't yet have time to set up a MinGW build environment, so I rely on binaries built by others). Does anyone else see this on MS-Windows? The only thing that is both peculiar and common to the two machines where I have this problem is that both of them have Active Window Tracking (a.k.a. focus follows mouse) feature of the window manager set to ON. Suggestions for further testing and requests for additional information are welcome. TIA _______________________________________________ Emacs-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/emacs-devel
