Re: prevent raising a frame from also input-focusing it

[chad <yandros@gmail.com>]

This is largely a function of the user's window manager (of which
there are dozens in active use), not emacs.

The reason that you haven't noticed it under MSWindows is that 
you (mostly) don't get a choice of window managers there. 
Presumably, whatever wm you're using under GNU/Linux (which 
might be controlled by your MSWindows machine, for example if
you're using an MSWindows X Server) uses the behavior you like
by default.

Focus-on-raise is the default behavior of many window managers.
How to change it depends entirely on the wm in question.

Hope that helps,
~Chad

> On 30 Nov 2014, at 10:59, Drew Adams <drew.adams@oracle.com> wrote:
> 
> I normally use Emacs on MS Windows.  I sometimes use Emacs
> on GNU/Linux, but the available version there is Emacs 21 (!).
> 
> I don't have any problem in either of those contexts,
> preventing Emacs from coupling frame raising with
> input-focusing the raised frame.  At least I haven't
> noticed a problem.  (I cannot connect now to the GNU/Linux
> machine, to check, but I think I would have noticed such a
> glaring problem.)
> 
> On Windows I just set option `w32-grab-focus-on-raise' to nil.
> 
> On GNU/Linux (Emacs 21) I don't do anything special to prevent
> automatic focusing of a raised frame, AFAIK.  Why I haven't
> noticed a problem with GNU/Linux, Emacs 21, I don't know.
> 
> I received a report from a user of oneonone.el, a library
> that (by default) creates a standalone minibuffer frame.
> It reports that the behavior on GNU/Emacs is always like
> that in Windows with non-nil `w32-grab-focus-on-raise':
> *raising a frame always focuses it.*
> 
> Can users change this, please?  (Is this possible already?)
> 
> Here's a simple recipe, to show why this is unusable with
> a standalone minibuffer frame:
> 
> emacs -Q -l "test.el" -f "test"
> 
> Where test.el has this:
> (defun test ()
>  ""
>  (interactive)
>  (setq default-frame-alist (list (cons 'minibuffer nil)))
>  (setq pop-up-frames  t)
>  (setq minibuffer-frame-alist
>        (list (cons 'height 2) (cons 'minibuffer 'only)))
>  (make-frame minibuffer-frame-alist)
>  (setq minibuffer-auto-raise t))
> 
> In *scratch*, do `C-SPC'.  You see message `Mark activated'
> in the echo area.  But the input focus is switched to the
> minibuffer frame, away from the *scratch* frame!
> 
> (That is what I see on MS Windows, with nil
> `w32-grab-focus-on-raise', and IIUC it is the reported
> behavior for GNU/Linux.)
> 
> To print a message in *output* area (echo area), Emacs has
> also switched the *input* focus to that frame.  This design
> makes no sense to me.  It certainly makes trying to use a
> standalone minibuffer frame problematic.
> 
> Please let me know how users can prevent this input focus
> switch on non-Windows platforms.  Thx.
> 
> Why should raising a frame be coupled with input-focusing
> it?  Why shouldn't users be able to control this?
> (And why should such coupling be the default behavior?)
>