CycleWS.toggleWS bug?
Hi, I have found what seems to me a (theoretical) bug in Xmonad.Actions.CycleWS.ToggleWS. Or if this is not a bug I would like to find out why not :) The code for the function is ------ -- | Toggle to the workspace displayed previously. toggleWS :: X () toggleWS = windows $ view =<< tag . head . hidden ------ What if there are no hidden workspaces? Would the empty list exception be caught somewhere? This may be an edge case not worth worrying about but it still bothers me somehow :) Cheers, Alexey
On Wed, Sep 16, 2009 at 08:32:29PM +1000, Alexey Feigin wrote:
What if there are no hidden workspaces? Would the empty list exception be caught somewhere?
Yes, XMonad does some exception handling here, so this won't cause any damage. It would be different if sth like that would be found in for example manage hooks. I just tried my config with just one single workspace, and the "doF (W.shift $ myWorkspaces !! 5)" did indeed cause XMonad to crash completly.
On Wed, Sep 16, 2009 at 12:48:10PM +0200, Nils wrote:
On Wed, Sep 16, 2009 at 08:32:29PM +1000, Alexey Feigin wrote:
What if there are no hidden workspaces? Would the empty list exception be caught somewhere?
Yes, XMonad does some exception handling here, so this won't cause any damage.
It would be different if sth like that would be found in for example manage hooks. I just tried my config with just one single workspace, and the "doF (W.shift $ myWorkspaces !! 5)" did indeed cause XMonad to crash completly.
Yikes! If you can make xmonad crash, it is a bug. Why are managehooks different? How can we prevent bogus managehooks from crashing xmonad? -Brent
* On Wednesday, September 16 2009, Brent Yorgey wrote:
Yikes! If you can make xmonad crash, it is a bug. Why are managehooks different? How can we prevent bogus managehooks from crashing xmonad?
-Brent
in XMonad.Operations (line 71) we have the following: ] manage :: Window -> X () ] ... ] g <- fmap appEndo $ userCodeDef (Endo id) (runQuery mh w) ] windows (g . f) It looks like we are catching whether a function is undefined, not whether the function could be undefined for some input. I'm not sure about it, but I think laziness (without involving partially applied functions) can hide exceptions too. Anybody have ideas where to put the catch in manage in such a way that the effects of f still happen, without much copy-paste of the windows function? (or can the effects of f just be left to not happen?) -- Adam
Excerpts from Alexey Feigin's message of Wed Sep 16 04:32:29 -0600 2009:
Hi,
I have found what seems to me a (theoretical) bug in Xmonad.Actions.CycleWS.ToggleWS. Or if this is not a bug I would like to find out why not :)
The code for the function is ------ -- | Toggle to the workspace displayed previously. toggleWS :: X () toggleWS = windows $ view =<< tag . head . hidden ------
This has been fixed in darcs. It's not purely theoretical, I know of at least one user that starts with only two workspaces, one per screen, then uses dynamic workspaces to create and remove workspaces as needed. Luckily he wasn't using toggleWS, hehe. Current version: toggleWS = do hs <- gets (hidden . windowset) unless (null hs) (windows . view . tag $ head hs) -- wmw
participants (5)
-
Adam Vogt -
Alexey Feigin -
Brent Yorgey -
Nils -
Wirt Wolff