[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
prevent raising a frame from also input-focusing it
From: |
Drew Adams |
Subject: |
prevent raising a frame from also input-focusing it |
Date: |
Sun, 30 Nov 2014 10:59:26 -0800 (PST) |
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?)
- prevent raising a frame from also input-focusing it,
Drew Adams <=