May 2012 - xmonad - Haskell.org

Re: [xmonad] Strange workspace switching bug in my config
by Leo Alekseyev 18 May '12

18 May '12

On Sun, May 13, 2012 at 8:45 AM, Norbert Zeh <nzeh(a)cs.dal.ca> wrote: > Leo Alekseyev [2012.05.13 0127 -0400]: >> Hi all, >> A couple of years back I made the following addition to my xmonad.hs: >> instead of 10 workspaces, it admits 20 workspaces, logically arranged >> in two rows of 10. I think of it as having a "scratch" workspace for >> every main workspace, and I use up/down arrows to switch between the >> main and the scratch workspace. For instance, if you are on workspace >> 4, Mod4-<down> will move to workspace 4SCR and Mod4-<up> will move >> back to workspace 4. >> >> Recently this config started misbehaving (without any changes to >> xmonad.hs, but with possible changes in xmonad/GHC version to 0.10 and >> 7.4.1 as my system was upgraded). In particular, in the example >> above, now Mod4-<down> moves from workspace 4 to workspace 3SCR and >> Mod4-<up> then moves from 3SCR to 2. To fix it, I have to log in and >> out of X, but the problem always reoccurs, possibly after sleep/resume >> cycle(?). >> >> The embarrassing thing here is that I haven't touched Haskell in a >> while, and barely grok my config anymore, so I don't know where to >> start troubleshooting. The code I described seems straightforward >> enough, so it's my hope that maybe someone here can tell me what is >> going on without too much effort... >> >> The relevant parts of my config are below, and the full file in its >> horrifying glory is at http://hpaste.org/68453. If someone seems >> something obviously amiss, please shout... >> >> --leo >> >> myWorkspaces = ["1:terminals", "2:emacs", "3:web", "4", "5", "6", >> "7","8","9","0"] ++ map (\x -> show x ++ "SCR") ([1..9]++[0]) >> ..... >> >> zeroSub 0 = 10 >> zeroSub x = x >> >> jumpToMain = gets windowset >>= \W.StackSet { W.current = W.Screen { >> W.workspace = w } } -> withNthWorkspace W.greedyView (-1+(zeroSub $ >> read [head(W.tag w)])) >> jumpToScratch = gets windowset >>= \W.StackSet { W.current = W.Screen >> { W.workspace = w } } -> withNthWorkspace W.greedyView (9+(zeroSub $ >> read [head(W.tag w)])) > > The math here looks all wrong, and I'm surprised that it worked at all before. > What you want, I think, is the following: > > jumpToMain = gets (W.tag . W.workspace . W.current . windowset) > >>= W.greedyView . toMain > where > toMain ws = [head ws] > > jumpToScratch = gets (W.tag . W.workspace . W.current . windowset) > >>= W.greedyView . toScratch > where > toScratch ws | length ws == 1 = ws ++ "SCR" > | otherwise = ws > > The idea here is that you simply want to add or take away the "SCR" suffix in > the workspace tag or, in the latter case, do nothing if it's already present. Hi Norbert, Yes, my original math was kind of dodgy... Your solution seems better, but it doesn't compile for me... any ideas? xmonad.hs:452:14: No instance for (MonadState XState ((->) (W.StackSet [Char] l3 a3 s3 sd3))) arising from a use of `gets' Possible fix: add an instance declaration for (MonadState XState ((->) (W.StackSet [Char] l3 a3 s3 sd3))) In the first argument of `(>>=)', namely `gets (tag . W.workspace . W.current . windowset)' In the expression: gets (tag . W.workspace . W.current . windowset) >>= W.greedyView . toMain In an equation for `jumpToMain': jumpToMain = gets (tag . W.workspace . W.current . windowset) >>= W.greedyView . toMain where toMain ws = [head ws] xmonad.hs:456:17: No instance for (MonadState XState ((->) (W.StackSet [Char] l1 a1 s1 sd1))) arising from a use of `gets' Possible fix: add an instance declaration for (MonadState XState ((->) (W.StackSet [Char] l1 a1 s1 sd1))) In the first argument of `(>>=)', namely `gets (tag . W.workspace . W.current . windowset)' In the expression: gets (tag . W.workspace . W.current . windowset) >>= W.greedyView . toScratch In an equation for `jumpToScratch': jumpToScratch = gets (tag . W.workspace . W.current . windowset) >>= W.greedyView . toScratch where toScratch ws | length ws == 1 = ws ++ "SCR" | otherwise = ws

4 9

darcs patch: Config.hs: rm commented out keybinding (... (and 2 more)
by gwern0＠gmail.com 16 May '12

16 May '12

Address Adam's complaint that Janis used a version prior to his patch. 3 patches for repository community.haskell.org:/srv/code/xmonad: Thu Jan 12 19:01:15 EST 2012 gwern0(a)gmail.com * Config.hs: rm commented out keybinding (dead for years) Thu Jan 12 20:04:10 EST 2012 gwern0(a)gmail.com * Config.hs: implement mod-shift-/ newbie keybinding guide per http://code.google.com/p/xmonad/issues/detail?id=182 Wed May 16 17:13:52 EDT 2012 gwern0(a)gmail.com * HCAR.tex: update per Janis

1 0

darcs patch: Config.hs: rm commented out keybinding (... (and 2 more)
by gwern0＠gmail.com 16 May '12

16 May '12

3 patches for repository community.haskell.org:/srv/code/xmonad: Thu Jan 12 19:01:15 EST 2012 gwern0(a)gmail.com * Config.hs: rm commented out keybinding (dead for years) Thu Jan 12 20:04:10 EST 2012 gwern0(a)gmail.com * Config.hs: implement mod-shift-/ newbie keybinding guide per http://code.google.com/p/xmonad/issues/detail?id=182 Sun May 13 17:15:22 EDT 2012 gwern0(a)gmail.com * HCAR.tex: update per Janis

3 2

Re: [xmonad] Strange workspace switching bug in my config
by Norbert Zeh 15 May '12

15 May '12

Leo Alekseyev [2012.05.15 1049 -0400]: > On Tue, May 15, 2012 at 7:20 AM, Norbert Zeh <nzeh(a)cs.dal.ca> wrote: > > wagnerdm(a)seas.upenn.edu [2012.05.14 2219 -0400]: > >> Quoting Leo Alekseyev <dnquark(a)gmail.com>: > >> > >> >On Sun, May 13, 2012 at 8:45 AM, Norbert Zeh <nzeh(a)cs.dal.ca> wrote: > >> >>>myWorkspaces = ["1:terminals", "2:emacs", "3:web", "4", "5", "6", > >> >>>"7","8","9","0"] ++ map (\x -> show x ++ "SCR") ([1..9]++[0]) > >> >>>..... > >> >>> > >> >>>zeroSub 0 = 10 > >> >>>zeroSub x = x > >> >>> > >> >>>jumpToMain = gets windowset >>= \W.StackSet { W.current = W.Screen { > >> >>>W.workspace = w } } -> withNthWorkspace W.greedyView (-1+(zeroSub $ > >> >>>read [head(W.tag w)])) > >> >>>jumpToScratch = gets windowset >>= \W.StackSet { W.current = W.Screen > >> >>>{ W.workspace = w } } -> withNthWorkspace W.greedyView (9+(zeroSub $ > >> >>>read [head(W.tag w)])) > >> >> > >> >>The math here looks all wrong, and I'm surprised that it worked > >> >>at all before. > >> > >> The math looks fine to me, and in fact your suggestion: > >> > >> >>What you want, I think, is the following: > >> >> > >> >>jumpToMain = gets (W.tag . W.workspace . W.current . windowset) > >> >> >>= W.greedyView . toMain > >> >> where > >> >> toMain ws = [head ws] > >> >> > >> >>jumpToScratch = gets (W.tag . W.workspace . W.current . windowset) > >> >> >>= W.greedyView . toScratch > >> >> where > >> >> toScratch ws | length ws == 1 = ws ++ "SCR" > >> >> | otherwise = ws > >> > >> is the one that looks dodgy to me. Notice that his main workspace > >> names are things like "3:web", but the SCR-version is just "3SCR"! > >> In fact, I would humbly suggest that this paragraph: > > > > Oops. I overlooked that the primary workspaces were not just numbered. My bad. > > I still don't get the math in the original code snippet. zeroSub has an effect > > only when its argument is 0. So, for any starting workspace except "0" or > > "0SCR", say its number is x, the above code goes to workspace x-1 or x+9. It > > should, however, go to workspace x-10 or x+10 and that conditionally on whether > > the main/scratch workspace is already visible. What is it I don't understand > > here? > > My original understanding was this: I have an array of workspaces like so: > [1, 2, ...9, 0, 1SCR, 2SCR, ... 0SCR] > > When I want to go from e.g. 2 to 2SCR, I want element 11 in this > 0-indexed array. So, I get the head of the tag, I assume /read/ > converts it to an integer, and I add 9 to it, and hope that > withNthWorkspace on the 11th array element will do the right thing. > By that logic, to go from 2SCR back to 2, I need to subtract 11 to get > element 1 of the array. However, when I originally wrote that code, > this didn't work right, and I put in random numbers until for some > reason putting in 1 worked. (Yes, programming by coincidence and > all.) Oh man, sleep deprivation is really taking its toll it seems. Of course you're right and the math now looks perfectly fine to me. Now I'm just as stumped as you that this does not work. Cheers, Norbert

1 0

Re: [xmonad] Strange workspace switching bug in my config
by Leo Alekseyev 15 May '12

15 May '12

On Tue, May 15, 2012 at 10:49 AM, Leo Alekseyev <dnquark(a)gmail.com> wrote: > On Tue, May 15, 2012 at 7:20 AM, Norbert Zeh <nzeh(a)cs.dal.ca> wrote: >> wagnerdm(a)seas.upenn.edu [2012.05.14 2219 -0400]: >>> Quoting Leo Alekseyev <dnquark(a)gmail.com>: >>> >>> >On Sun, May 13, 2012 at 8:45 AM, Norbert Zeh <nzeh(a)cs.dal.ca> wrote: >>> >>>myWorkspaces = ["1:terminals", "2:emacs", "3:web", "4", "5", "6", >>> >>>"7","8","9","0"] ++ map (\x -> show x ++ "SCR") ([1..9]++[0]) >>> >>>..... >>> >>> >>> >>>zeroSub 0 = 10 >>> >>>zeroSub x = x >>> >>> >>> >>>jumpToMain = gets windowset >>= \W.StackSet { W.current = W.Screen { >>> >>>W.workspace = w } } -> withNthWorkspace W.greedyView (-1+(zeroSub $ >>> >>>read [head(W.tag w)])) >>> >>>jumpToScratch = gets windowset >>= \W.StackSet { W.current = W.Screen >>> >>>{ W.workspace = w } } -> withNthWorkspace W.greedyView (9+(zeroSub $ >>> >>>read [head(W.tag w)])) >>> >> >>> >>The math here looks all wrong, and I'm surprised that it worked >>> >>at all before. >>> >>> The math looks fine to me, and in fact your suggestion: >>> >>> >>What you want, I think, is the following: >>> >> >>> >>jumpToMain = gets (W.tag . W.workspace . W.current . windowset) >>> >> >>= W.greedyView . toMain >>> >> where >>> >> toMain ws = [head ws] >>> >> >>> >>jumpToScratch = gets (W.tag . W.workspace . W.current . windowset) >>> >> >>= W.greedyView . toScratch >>> >> where >>> >> toScratch ws | length ws == 1 = ws ++ "SCR" >>> >> | otherwise = ws >>> >>> is the one that looks dodgy to me. Notice that his main workspace >>> names are things like "3:web", but the SCR-version is just "3SCR"! >>> In fact, I would humbly suggest that this paragraph: >> >> Oops. I overlooked that the primary workspaces were not just numbered. My bad. >> I still don't get the math in the original code snippet. zeroSub has an effect >> only when its argument is 0. So, for any starting workspace except "0" or >> "0SCR", say its number is x, the above code goes to workspace x-1 or x+9. It >> should, however, go to workspace x-10 or x+10 and that conditionally on whether >> the main/scratch workspace is already visible. What is it I don't understand >> here? > > My original understanding was this: I have an array of workspaces like so: > [1, 2, ...9, 0, 1SCR, 2SCR, ... 0SCR] > > When I want to go from e.g. 2 to 2SCR, I want element 11 in this > 0-indexed array. So, I get the head of the tag, I assume /read/ > converts it to an integer, and I add 9 to it, and hope that > withNthWorkspace on the 11th array element will do the right thing. > By that logic, to go from 2SCR back to 2, I need to subtract 11 to get > element 1 of the array. However, when I originally wrote that code, > this didn't work right, and I put in random numbers until for some > reason putting in 1 worked. (Yes, programming by coincidence and > all.) > > Speaking of programming by coincidence, I changed the numbers to +10 > and -0, and things started working. Then I logged in and out, and now > I'm back to off-by-one, but in a different direction, i.e. 2 takes me > to 3SCR and going back takes me to 4, etc... I put in my old code, > and now things work again, but if history is any indication, it will > break some time later today or tomorrow. > > I'm clearly misunderstanding something about how workspace switching works... What I said above about subtracting 11 is of course wrong: by my logic, I read in the head of the tag "2SCR", i.e. "2", get an int, subtract 1, and go to element 1 of the workspace array, which should have workspace 1. So my math is consistent with my mental model of how workspace switching works. (Why do I have to realize this 3 seconds after I hit send? :P)

1 0

Regexp WM_NAME ?
by Pablo Olmos de Aguilera C. 14 May '12

14 May '12

In pentadactyl (a firefox addon) you can write in an external editor instead a textbox, by default it spawns a gvim window and everytime it opens a pentadactyl.txt in tmp folder. Imho that behaviour is way more easier writing on a floating window. Using xprop I found the WM_NAME it's the only variable that doesn't change, so I thought that using it in my myManageHook would do it. $ xprop | grep 'WM_NAME' WM_NAME(STRING) = "pentadactyl.txt (/tmp) - GVIM" myManageHook = (composeAll , concat $ [ , [ className =? "stalonetray" --> doIgnore] -- a lot of output removed -- , [ title =? "pentadactyl.txt (/tmp) - GVIM" --> doFloat] ] I restarted xmonad, reopened the editor and I found that it doesn't work, I tried to check wm_name again, and guess what? WM_NAME(STRING) = "pentadactyl.txt (/tmp) - GVIM1" Obviously the last part "GVIM" changes all the time, so I can't know in advance which is gonna pick. There's some way to regexp the wm_name part? Until now, I couldn't find anything about this topic :( Regards, -- Pablo Olmos de Aguilera Corradini - @PaBLoX http://www.glatelier.org/ http://about.me/pablox/ http://www.linkedin.com/in/pablooda/ Linux User: #456971 - http://counter.li.org/

3 6

Strange workspace switching bug in my config
by Leo Alekseyev 13 May '12

13 May '12

Hi all, A couple of years back I made the following addition to my xmonad.hs: instead of 10 workspaces, it admits 20 workspaces, logically arranged in two rows of 10. I think of it as having a "scratch" workspace for every main workspace, and I use up/down arrows to switch between the main and the scratch workspace. For instance, if you are on workspace 4, Mod4-<down> will move to workspace 4SCR and Mod4-<up> will move back to workspace 4. Recently this config started misbehaving (without any changes to xmonad.hs, but with possible changes in xmonad/GHC version to 0.10 and 7.4.1 as my system was upgraded). In particular, in the example above, now Mod4-<down> moves from workspace 4 to workspace 3SCR and Mod4-<up> then moves from 3SCR to 2. To fix it, I have to log in and out of X, but the problem always reoccurs, possibly after sleep/resume cycle(?). The embarrassing thing here is that I haven't touched Haskell in a while, and barely grok my config anymore, so I don't know where to start troubleshooting. The code I described seems straightforward enough, so it's my hope that maybe someone here can tell me what is going on without too much effort... The relevant parts of my config are below, and the full file in its horrifying glory is at http://hpaste.org/68453. If someone seems something obviously amiss, please shout... --leo myWorkspaces = ["1:terminals", "2:emacs", "3:web", "4", "5", "6", "7","8","9","0"] ++ map (\x -> show x ++ "SCR") ([1..9]++[0]) ..... zeroSub 0 = 10 zeroSub x = x jumpToMain = gets windowset >>= \W.StackSet { W.current = W.Screen { W.workspace = w } } -> withNthWorkspace W.greedyView (-1+(zeroSub $ read [head(W.tag w)])) jumpToScratch = gets windowset >>= \W.StackSet { W.current = W.Screen { W.workspace = w } } -> withNthWorkspace W.greedyView (9+(zeroSub $ read [head(W.tag w)])) .... , ("M-<Up>", jumpToMain) , ("M-<Down>", jumpToScratch)

1 0

* UrgencyHooks made available as Window -> X () functions [patch]
by David McLean 10 May '12

10 May '12

My previous attempt at this patch was flawed, as gwern pointed out, in that it completely broke backward compatibility with all existing configurations using the module. This variation addresses that issue, preserving backward compatibility completely. 1 patch for repository http://code.haskell.org/XMonadContrib: Fri May 4 16:23:39 EST 2012 gopsychonauts(a)gmail.com * UrgencyHooks made available as Window -> X () functions Adds an UrgencyHook instance for the type Window -> X (), allowing any such functions to be used directly as UrgencyHooks. The Show and Read constraints were removed from the UrgencyHook class in order to permit this; these constraints were required only in a historical implementation of the module, which used a layout modifier. All existing configurations using UrgencyHooks should remain fully functional. New configs may make use of this modification by declaring their UrgencyHook as a simple Window -> X () function.

3 2

silly behavior of killWord in XMonad.Prompt
by Brent Yorgey 10 May '12

10 May '12

I realized today that the behavior of killWord from XMonad.Prompt is surprising to me. In particular, when you iterate killWord, it deletes first a word, then a space, then the next word, then the next space, and so on. I (an emacs user) expect killWord to delete a word AND any whitespace that happens to come before it. (Hmm... I tested with vim and it seems that 'dw' deletes a word along with any TRAILING whitespace. So emacs and vim differ here... but the point is that killWord emulates neither.) I looked into it and it turns out that the behavior of killWord is even sillier than I thought. It deletes an entire word of non-whitespace characters *or a single space*. (So if there are multiple spaces you have to call killWord once for each space before you finally get to delete the word that comes after.) And if the next character is a tab it doesn't delete anything at all! For concreteness, here's the change I made: diff -rN old-XMonadContrib/XMonad/Prompt.hs new-XMonadContrib/XMonad/Prompt.hs 525,528c525 < delNextWord w = < case w of < ' ':x -> x < word -> snd . break isSpace $ word --- > delNextWord = snd . break isSpace . dropWhile isSpace Thoughts? If anyone really likes the old behavior then I can make two versions. Or if there is consensus that the old behavior is silly and the new behavior is better, then I'll just push the above change. I could also be talked into swapping the order of the break and dropWhile in order to emulate vim; I don't really care as long as it's one of the two. -Brent

8 10

bringing xmonad into the threaded world
by wagnerdm＠seas.upenn.edu 08 May '12

08 May '12

There have been various times when I've wished I could just spawn a thread in xmonad. Just recently, for example, it was pointed out to me that the default mod+q binding starts a brand new process just to keep xmonad responsive while it recompiles the configuration file. This is silly. Here is a patch bundle that makes xmonad ask X to be thread-safe, and rewrites the default mod+q binding to take advantage of the new thread safety. ~d

4 11