all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* prevent raising a frame from also input-focusing it
@ 2014-11-30 18:59 Drew Adams
  2014-11-30 23:48 ` chad
  0 siblings, 1 reply; 6+ messages in thread
From: Drew Adams @ 2014-11-30 18:59 UTC (permalink / raw)
  To: emacs-devel

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?)



^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2014-12-01 21:31 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-11-30 18:59 prevent raising a frame from also input-focusing it Drew Adams
2014-11-30 23:48 ` chad
2014-12-01  0:14   ` Drew Adams
2014-12-01 19:26   ` Alan Schmitt
2014-12-01 19:59     ` chad
2014-12-01 21:31       ` Alan Schmitt

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.