unofficial mirror of emacs-devel@gnu.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

* Re: prevent raising a frame from also input-focusing it
  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
  0 siblings, 2 replies; 6+ messages in thread
From: chad @ 2014-11-30 23:48 UTC (permalink / raw)
  To: Drew Adams; +Cc: emacs-devel

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




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

* RE: prevent raising a frame from also input-focusing it
  2014-11-30 23:48 ` chad
@ 2014-12-01  0:14   ` Drew Adams
  2014-12-01 19:26   ` Alan Schmitt
  1 sibling, 0 replies; 6+ messages in thread
From: Drew Adams @ 2014-12-01  0:14 UTC (permalink / raw)
  To: chad; +Cc: emacs-devel

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



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

* Re: prevent raising a frame from also input-focusing it
  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
  1 sibling, 1 reply; 6+ messages in thread
From: Alan Schmitt @ 2014-12-01 19:26 UTC (permalink / raw)
  To: emacs-devel

[-- Attachment #1: Type: text/plain, Size: 388 bytes --]

On 2014-11-30 15:48, chad <yandros@gmail.com> writes:

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

Is there an option similar to `w32-grab-focus-on-raise-frame' on the OS
X version of emacs? I searched for it but could not find anything.

Thanks,

Alan

-- 
OpenPGP Key ID : 040D0A3B4ED2E5C7

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 494 bytes --]

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

* Re: prevent raising a frame from also input-focusing it
  2014-12-01 19:26   ` Alan Schmitt
@ 2014-12-01 19:59     ` chad
  2014-12-01 21:31       ` Alan Schmitt
  0 siblings, 1 reply; 6+ messages in thread
From: chad @ 2014-12-01 19:59 UTC (permalink / raw)
  To: Alan Schmitt; +Cc: emacs-devel


> On 01 Dec 2014, at 11:26, Alan Schmitt <alan.schmitt@polytechnique.org> wrote:
> 
> On 2014-11-30 15:48, chad <yandros@gmail.com> writes:
> 
>> Focus-on-raise is the default behavior of many window managers.
>> How to change it depends entirely on the wm in question.
> 
> Is there an option similar to `w32-grab-focus-on-raise-frame' on the OS
> X version of emacs? I searched for it but could not find anything.

To the best of my knowledge, this functionality is not supported
by the OS at all, and can't be done via Emacs. It's bigger half of
the reason that I stopped using a dedicated minibuffer frame (the
lesser half being that I started using full-screen frames).

Sorry I couldn't be more help. I'd love to find out that I'm wrong.

~Chad


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

* Re: prevent raising a frame from also input-focusing it
  2014-12-01 19:59     ` chad
@ 2014-12-01 21:31       ` Alan Schmitt
  0 siblings, 0 replies; 6+ messages in thread
From: Alan Schmitt @ 2014-12-01 21:31 UTC (permalink / raw)
  To: emacs-devel

[-- Attachment #1: Type: text/plain, Size: 927 bytes --]

On 2014-12-01 11:59, chad <yandros@gmail.com> writes:

>> Is there an option similar to `w32-grab-focus-on-raise-frame' on the OS
>> X version of emacs? I searched for it but could not find anything.
>
> To the best of my knowledge, this functionality is not supported
> by the OS at all, and can't be done via Emacs. It's bigger half of
> the reason that I stopped using a dedicated minibuffer frame (the
> lesser half being that I started using full-screen frames).
>
> Sorry I couldn't be more help. I'd love to find out that I'm wrong.

Thank you for your reply. I've settled for the moment on not raising the
minibuffer at all, which works great as long as it's not obscured. I was
also using full-screen frames, but as I'm experimenting with the
multiple frames approach, I more clearly see the advantages of
both. Which is quite frustrating in a way ;)

Alan

-- 
OpenPGP Key ID : 040D0A3B4ED2E5C7

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 494 bytes --]

^ 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 public inbox

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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).