My situation is that I'm using Thunderbird and its External Editor plug-in to write mail. When I invoke the external editor, it brings up an emacs window (calling through emacsclient). I have a manage hook that puts emacs windows into a particular workspace, but I don't want e-mail composition emacs windows to go there. I thought I could handle this by looking at an emacs window's WM_NAME in my ManageHook, but unfortunately, it seems at this point that the title is still just "emacs@<myhost>", which is not helpful. It seems that the useful title (which is of the form "<something-or-other>.eml") gets created a little later. So, I thought I would put in a general eventhandler to watch for a property change, and to then do the shift to the appropriate workspace. So, I added handleEventHook = mappend myhandlePropEvent (handleEventHook defaultConfig) to my modifications of the default config. I then have myhandlePropEvent ev = case ev of PropertyEvent {} -> let w = ev_window ev ... Through calls to trace, I can see that I am indeed picking up on the desired event (the change in the window's name), and I have a window (w above) to hand, but I don't know how to do things to it. My cursory examination of the relevant APIs suggested I could do action <- runQuery (doShift "mail") w giving me a handle on an Endo Windowset, but I don't know how to lift that into the X monad (where I have to eventually return $ All True). Can I use the withWindowSet function somehow? Michael
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 5/1/11 20:28 , Michael Norrish wrote:
My situation is that I'm using Thunderbird and its External Editor plug-in to write mail. When I invoke the external editor, it brings up an emacs window (calling through emacsclient). I have a manage hook that puts emacs windows into a particular workspace, but I don't want e-mail composition emacs windows to go there.
I thought I could handle this by looking at an emacs window's WM_NAME in my ManageHook, but unfortunately, it seems at this point that the title is still just "emacs@<myhost>", which is not helpful. It seems that the useful title (which is of the form "<something-or-other>.eml") gets created a little later.
So, I thought I would put in a general eventhandler to watch for a property change, and to then do the shift to the appropriate workspace. So, I added
handleEventHook = mappend myhandlePropEvent (handleEventHook defaultConfig)
to my modifications of the default config.
I then have
myhandlePropEvent ev = case ev of PropertyEvent {} -> let w = ev_window ev ...
Through calls to trace, I can see that I am indeed picking up on the desired event (the change in the window's name), and I have a window (w above) to hand, but I don't know how to do things to it. My cursory examination of the relevant APIs suggested I could do
action <- runQuery (doShift "mail") w
giving me a handle on an Endo Windowset, but I don't know how to lift that into the X monad (where I have to eventually return $ All True). Can I use the withWindowSet function somehow?
I saw you asking about this in #xmonad and left a response message, but I guess you never checked back in. You want to do something like windows (W.shift "mail" w) which reruns the layout with the specified modification. - -- brandon s. allbery [linux,solaris,freebsd,perl] allbery.b@gmail.com system administrator [openafs,heimdal,too many hats] kf8nh -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk2+BuQACgkQIn7hlCsL25XEpQCgzyCSC1iOCaPxUEoQCM+JXde/ q9wAmwYgbnk02RlF/pGXarM9D1peg6ty =eVRl -----END PGP SIGNATURE-----
On 02/05/11 11:20, Brandon S Allbery KF8NH wrote:
On 5/1/11 20:28 , Michael Norrish wrote:
Through calls to trace, I can see that I am indeed picking up on the desired event (the change in the window's name), and I have a window (w above) to hand, but I don't know how to do things to it. My cursory examination of the relevant APIs suggested I could do
action <- runQuery (doShift "mail") w
giving me a handle on an Endo Windowset, but I don't know how to lift that into the X monad (where I have to eventually return $ All True). Can I use the withWindowSet function somehow?
I saw you asking about this in #xmonad and left a response message, but I guess you never checked back in. You want to do something like
windows (W.shift "mail" w)
which reruns the layout with the specified modification.
This doesn't quite work because w is a Window, not a WindowSet. However, the following does appear to do the right thing action <- runQuery (doShift "mail") w windows (appEndo action) It still seems a bit on the convoluted side. Is there a way of getting an appropriate WindowSet from the w :: Window that I do have? Best, Michael
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 5/1/11 21:36 , Michael Norrish wrote:
On 02/05/11 11:20, Brandon S Allbery KF8NH wrote:
On 5/1/11 20:28 , Michael Norrish wrote:
giving me a handle on an Endo Windowset, but I don't know how to lift that into the X monad (where I have to eventually return $ All True). Can I use the withWindowSet function somehow? windows (W.shift "mail" w) which reruns the layout with the specified modification.
This doesn't quite work because w is a Window, not a WindowSet. However, the following does appear to do the right thing
action <- runQuery (doShift "mail") w windows (appEndo action)
Yeh, I did that without looking fully; shift uses the focused window instead of a specified one. Sorry about that. The correct expression looks to be
windows (W.shiftWin "mail" w)
- -- brandon s. allbery [linux,solaris,freebsd,perl] allbery.b@gmail.com system administrator [openafs,heimdal,too many hats] kf8nh -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk2+D+kACgkQIn7hlCsL25ULZQCgg9jahzVEObd9I++ZGl4Lr6xl c+sAnjVN1EzHpv2nl3QO8MxqBUQCszxD =eI+w -----END PGP SIGNATURE-----
On 02/05/11 11:59, Brandon S Allbery KF8NH wrote:
Yeh, I did that without looking fully; shift uses the focused window instead of a specified one. Sorry about that.
The correct expression looks to be
windows (W.shiftWin "mail" w)
Many thanks; that's just the thing. Thanks, Michael
On 02/05/11 12:18, Michael Norrish wrote:
On 02/05/11 11:59, Brandon S Allbery KF8NH wrote:
The correct expression looks to be
windows (W.shiftWin "mail" w)
Many thanks; that's just the thing.
I now have windows (W.focusWindow w . W.shiftWin "mail" w) as my X () action in my custom event-handler. The guards on this ensure that when an emacs window changes its name to something indicating an edit of an e-mail message, the above gets run. My standard manageHook otherwise moves all emacs windows to a different workspace. I.e., I have , className =? "Emacs" --> doShift "work" in the definition of myManageHook. Unfortunately, the focus and shift action above doesn't quite do the right thing when the "work" workspace is not visible. When I create the emacs mail-editing window in the "mail" workspace, and when the "work" space is not the other visible space (on the other monitor) nothing seems to happen. (I guess the emacs window really is created, but the manageHook immediately whips it away, so I never see it.) If I subsequently do a M-1 (which would normally take me to "work"), this doesn't take me there, but instead causes the emacs window to suddenly appear on my "mail" workspace. In this way, it seems as if I'm 'refreshing' the state of the workspaces so that I get what I expect. It's mildly annoying that the emacs window doesn't show up, but it's also disturbing that the functionality of M-1 is being overridden in this way. Michael
On 04/05/11 11:14, Michael Norrish wrote:
Unfortunately, the focus and shift action above doesn't quite do the right thing when the "work" workspace is not visible. When I create the emacs mail-editing window in the "mail" workspace, and when the "work" space is not the other visible space (on the other monitor) nothing seems to happen. (I guess the emacs window really is created, but the manageHook immediately whips it away, so I never see it.)
If I subsequently do a M-1 (which would normally take me to "work"), this doesn't take me there, but instead causes the emacs window to suddenly appear on my "mail" workspace. In this way, it seems as if I'm 'refreshing' the state of the workspaces so that I get what I expect. It's mildly annoying that the emacs window doesn't show up, but it's also disturbing that the functionality of M-1 is being overridden in this way.
Actually it's even more complicated than this: when I launch the external editor as above (and I don't see the emacs window appear), the mouse moves to the top middle of my left monitor. Focus stays in the right place. I've attached my whole xmonad.hs just in case there's something else funny going on with my setup. I'm on Ubuntu 10.10, running through /etc/gdm/xsession, and xmonad --version reports 0.9.1 Michael
participants (2)
-
Brandon S Allbery KF8NH -
Michael Norrish