emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Drew Adams
Subject: RE: prevent raising a frame from also input-focusing it
Date: Sun, 30 Nov 2014 16:14:19 -0800 (PST)

> 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

I think you misread what I wrote.  I do notice, and always have
noticed, it under MSWindows, which is why I set option
`w32-grab-focus-on-raise' to nil, as I said.  The case reported
where this is a problem is not Windows but, IIUC, GNU/Linux.

Which window mgr, I don't know, and you are right that a window mgr
might not provide any hooks for Emacs to provide, say, an option
similar to `w32-grab-focus-on-raise'.  But has there even been an
attempt to do that?

> is that you (mostly) don't get a choice of window managers there.

MSWindows has one window mgr, yes.  But at least Emacs users
on Windows have a choice in this matter, thanks to option
`w32-grab-focus-on-raise'.

> 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.

Not sure what you mean.  It is true that when I use GNU/Linux
(with Emacs 21), I am accessing it on a remote box from my
Windows laptop, using, for example, VNC (or any number of other
ways to connect, none of which I've found to be problematic in
this regard).

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

I expected as much, but I appreciate your reply.

Can we not hope for Emacs to provide something similar to
option  `w32-grab-focus-on-raise' for other popular window
mgrs?  If Emacs Dev cared more about the use case of a
standalone minibuffer, and frames in general, I expect that
we could.

Especially for an app such as Emacs that controls windows,
frames, cursor movement, focus, etc. by keyboard, it makes
little sense to suppose that the two different actions
(from a user point of view) of (1) raising a frame and
(2) input-focusing it should be coupled, with no easy way to
uncouple them.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]