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