sb> sb> Greg Klanderman <greg(a)alphatech.com&gt; writes: sb> sb> Prior to adding the variable and the code controlled by that variable sb> really evil stuff happened. Any new frame command (C-x 5 ...) threw sb> keyboard focus to the new frame regardless of whether the frame was sb> visible (at that time one could end up with keyboard focus on a frame sb> in another virtual desktop) and whether the frame was underneath the sb> mouse. OK, now I get it. I had not seen f-f-m used in pop-to-buffer, and was very confused by how the C code using f-f-m could have had any useful effect on its own. With my patch, it is now the case that select-frame is analogous to set-buffer when f-f-m is t, in that the frame selection is temporary and reverted after the command finishes. The checking of f-f-m in pop-to-buffer should not be needed any longer. Checking ... yes, that seems to be true. So the reason your f-f-m patch worked is that pop-to-buffer avoids select-frame and select-window when f-f-m is true. But any other code that called these (relatively rare) would lose, in fact worse than before the patch because now emacs focus would get set to the new frame, but the window manager would think the originally focused frame still had focus. The downside with my patch is that with f-f-m true, select-frame *cannot* actually change the focus. You *must* bind f-f-m to nil around the call and do a (sit-for 0) after select-window. Never fear - no mouse warping needed. Yes, that is truly evil. Are we agreed that with f-f-m true, C-x 5 o (other-frame) is the *only* command which should warp focus. Is it ever called non-interactively? (eg, should it check and only actually change focus when run interactively?) sb> sb> No. The opposite actually. It was intended for emacs to never sb> override the window manager. sb>