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