From codesite-noreply at google.com Mon Jan 6 05:27:11 2014 From: codesite-noreply at google.com (codesite-noreply at google.com) Date: Mon, 06 Jan 2014 05:27:11 +0000 Subject: [xmonad] Issue 562 in xmonad: Weird XMonad.Shell.Prompt behaviour with held down mouse button Message-ID: <0-3425899027203913298-15621622867246128952-codesite-noreply=google.com@googlecode.com> Status: New Owner: ---- New issue 562 by fuuze... at fuuzetsu.co.uk: Weird XMonad.Shell.Prompt behaviour with held down mouse button http://code.google.com/p/xmonad/issues/detail?id=562 What steps will reproduce the problem? 1. Bind the prompt in your xmonad.hs to a key 2. Hold down left mouse button 3. Spawn the prompt and try to use it What is the expected output? What do you see instead? I expect the prompt to behave as usual. Instead, when pressing keys such as return or ESC, I get visible characters instead and the prompt won't close. What version of the product are you using? On what operating system? xmonad 0.11 Linux misaki 3.12.3-gentoo #2 SMP Sat Dec 7 23:14:57 GMT 2013 i686 Intel(R) Core(TM)2 Duo CPU L7700 @ 1.80GHz GenuineIntel GNU/Linux Are you using an xmonad.hs? Please attach it and the output of "xmonad --recompile". The relevant line is > [ ((modMask x .|. controlMask, xK_p), shellPrompt defaultXPConfig) I can't show --recompile as my xmonad config currently doesn't build. Let me know if you need more info and I'll fix it up and post the output along with full config. Please provide any additional information below. -- You received this message because this project is configured to send all issue notifications to this address. You may adjust your notification preferences at: https://code.google.com/hosting/settings From eeva+xmonad at marvid.fr Mon Jan 6 13:03:58 2014 From: eeva+xmonad at marvid.fr (EEva) Date: Mon, 6 Jan 2014 14:03:58 +0100 Subject: [xmonad] xmonad Digest, Vol 82, Issue 1 In-Reply-To: References: Message-ID: <20140106130358.GA814@Ook.labo.lacl.fr> Sorry, I cannot reproduce that here. Le 06/01/14 ? 12:00, xmonad-request at haskell.org a ?crit: > Send xmonad mailing list submissions to > xmonad at haskell.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://www.haskell.org/mailman/listinfo/xmonad > or, via email, send a message with subject or body 'help' to > xmonad-request at haskell.org > > You can reach the person managing the list at > xmonad-owner at haskell.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of xmonad digest..." > > > Today's Topics: > > 1. Issue 562 in xmonad: Weird XMonad.Shell.Prompt behaviour with > held down mouse button (codesite-noreply at google.com) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 06 Jan 2014 05:27:11 +0000 > From: codesite-noreply at google.com > To: xmonad at haskell.org > Subject: [xmonad] Issue 562 in xmonad: Weird XMonad.Shell.Prompt > behaviour with held down mouse button > Message-ID: > <0-3425899027203913298-15621622867246128952-codesite-noreply=google.com at googlecode.com> > > Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes > > Status: New > Owner: ---- > > New issue 562 by fuuze... at fuuzetsu.co.uk: Weird XMonad.Shell.Prompt > behaviour with held down mouse button > http://code.google.com/p/xmonad/issues/detail?id=562 > > What steps will reproduce the problem? > 1. Bind the prompt in your xmonad.hs to a key > 2. Hold down left mouse button > 3. Spawn the prompt and try to use it > > What is the expected output? What do you see instead? > I expect the prompt to behave as usual. Instead, when pressing keys such as > return or ESC, I get visible characters instead and the prompt won't close. > > What version of the product are you using? On what operating system? > xmonad 0.11 > Linux misaki 3.12.3-gentoo #2 SMP Sat Dec 7 23:14:57 GMT 2013 i686 Intel(R) > Core(TM)2 Duo CPU L7700 @ 1.80GHz GenuineIntel GNU/Linux > > Are you using an xmonad.hs? Please attach it and the output of "xmonad > --recompile". > The relevant line is > > [ ((modMask x .|. controlMask, xK_p), shellPrompt defaultXPConfig) > > I can't show --recompile as my xmonad config currently doesn't build. Let > me know if you need more info and I'll fix it up and post the output along > with full config. > > Please provide any additional information below. > > > -- > You received this message because this project is configured to send all > issue notifications to this address. > You may adjust your notification preferences at: > https://code.google.com/hosting/settings > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > xmonad mailing list > xmonad at haskell.org > http://www.haskell.org/mailman/listinfo/xmonad > > > ------------------------------ > > End of xmonad Digest, Vol 82, Issue 1 > ************************************* -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From mle+hs at mega-nerd.com Fri Jan 10 20:58:21 2014 From: mle+hs at mega-nerd.com (Erik de Castro Lopo) Date: Sat, 11 Jan 2014 07:58:21 +1100 Subject: [xmonad] Trouble getting taffybar running Message-ID: <20140111075821.44b74d934a267c86d65f8570@mega-nerd.com> Hi all, I've just cabal installed it, created ~/.config/taffybar/taffybar.hs (from taffybar.hs.example in the git repo) but when I run taffybar it says : Error occurred while loading configuration file When I load the config into ghci it loads without a single warning or error. I'm running it from an xterm within an already running xmonad session that doesn't have any other panel of any sort. Where do the taffybar compile error messages go? Any clues? Cheers, Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/ From codesite-noreply at google.com Fri Jan 10 22:46:57 2014 From: codesite-noreply at google.com (codesite-noreply at google.com) Date: Fri, 10 Jan 2014 22:46:57 +0000 Subject: [xmonad] Issue 562 in xmonad: Weird XMonad.Shell.Prompt behaviour with held down mouse button In-Reply-To: <0-3425899027203913298-15621622867246128952-codesite-noreply=google.com@googlecode.com> References: <0-3425899027203913298-15621622867246128952-codesite-noreply=google.com@googlecode.com> Message-ID: <1-3425899027203913298-15621622867246128952-codesite-noreply=google.com@googlecode.com> Comment #1 on issue 562 by fuuze... at fuuzetsu.co.uk: Weird XMonad.Shell.Prompt behaviour with held down mouse button http://code.google.com/p/xmonad/issues/detail?id=562 Attached is my xmonad.hs considering someone on the mailing list could not replicate. Attachments: xmonad.hs 4.7 KB -- You received this message because this project is configured to send all issue notifications to this address. You may adjust your notification preferences at: https://code.google.com/hosting/settings From tyler at plantarum.ca Fri Jan 10 23:44:34 2014 From: tyler at plantarum.ca (Tyler Smith) Date: Fri, 10 Jan 2014 18:44:34 -0500 Subject: [xmonad] Xmobar tab completion Message-ID: <7a39470b-aa78-4854-9201-1eddcd73ee0e@email.android.com> Hello, I have been using xmonad for a few weeks. After updating via aptitude on Debian unstable a few days ago, xmobarno longer offers tab-completions. It still works, but I have to ype out the whole command name. The colour of the bar is now black as well. I found some discussion of this on a forum. A solution was to rebuild xmonad. Not knowing Haskell, I'm not sure how to do this. Is there another solution? If not, how do I rebuild xmonad - is this even possible with the Debian package, or do I need to install from source? Thanks, Tyler -------------- next part -------------- An HTML attachment was scrubbed... URL: From tyler at plantarum.ca Fri Jan 10 23:54:06 2014 From: tyler at plantarum.ca (Tyler Smith) Date: Fri, 10 Jan 2014 18:54:06 -0500 Subject: [xmonad] Losing dropdown menus Message-ID: Hi again, I'm running xmonad on Debian unstable. Mostly it's great. However, sometimes with some applications I cannot see drop-down menus. This happens with the Okular pdf viewer, but not always. I can't reproduce this consistently yet, but it happens about half the time. What happens: the app launches and runs fine. If I click on the top menu (file etc) the item looks 'depressed' as it should, but no dropdown menu appears. If this problem occurs, it persists for the entire time the app is open. This also happens with virtualbox. In this case, everytime I run it, the dropdowns are invisible/absent. However, I can access menu items using the keyboard arrows to blindly move through the menus. So virtualbox thinks the menu is there, I just can't see it. Any suggestions? Thanks, Tyler -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel at wagner-home.com Sat Jan 11 03:47:03 2014 From: daniel at wagner-home.com (Daniel Wagner) Date: Fri, 10 Jan 2014 19:47:03 -0800 Subject: [xmonad] Losing dropdown menus In-Reply-To: References: Message-ID: <1eda6516432d655f74b964a926a550bc@seas.upenn.edu> On 2014-01-10 15:54, Tyler Smith wrote: > I'm running xmonad on Debian unstable. Mostly it's great. However, > sometimes with some applications I cannot see drop-down menus. This > happens with the Okular pdf viewer, but not always. I can't reproduce > this consistently yet, but it happens about half the time. Perhaps this bug is related. http://code.google.com/p/xmonad/issues/detail?id=396 ~d From tyler at plantarum.ca Sat Jan 11 03:57:12 2014 From: tyler at plantarum.ca (Tyler Smith) Date: Fri, 10 Jan 2014 22:57:12 -0500 Subject: [xmonad] Losing dropdown menus In-Reply-To: <1eda6516432d655f74b964a926a550bc@seas.upenn.edu> References: <1eda6516432d655f74b964a926a550bc@seas.upenn.edu> Message-ID: <326c5123-12e4-4f0b-acae-1e395c8504e4@email.android.com> That sounds like exactly the same issue. With no resolution in over a year :( Thanks for the pointer, Tyler -------- Original Message -------- From: Daniel Wagner Sent: Fri Jan 10 22:47:03 EST 2014 To: xmonad at haskell.org Subject: Re: [xmonad] Losing dropdown menus On 2014-01-10 15:54, Tyler Smith wrote: > I'm running xmonad on Debian unstable. Mostly it's great. However, > sometimes with some applications I cannot see drop-down menus. This > happens with the Okular pdf viewer, but not always. I can't reproduce > this consistently yet, but it happens about half the time. Perhaps this bug is related. http://code.google.com/p/xmonad/issues/detail?id=396 ~d _______________________________________________ xmonad mailing list xmonad at haskell.org http://www.haskell.org/mailman/listinfo/xmonad From mle+hs at mega-nerd.com Mon Jan 13 02:30:49 2014 From: mle+hs at mega-nerd.com (Erik de Castro Lopo) Date: Mon, 13 Jan 2014 13:30:49 +1100 Subject: [xmonad] Trouble getting taffybar running In-Reply-To: <20140111075821.44b74d934a267c86d65f8570@mega-nerd.com> References: <20140111075821.44b74d934a267c86d65f8570@mega-nerd.com> Message-ID: <20140113133049.af12b106b888e6e2ba4059fb@mega-nerd.com> Erik de Castro Lopo wrote: > I've just cabal installed it, created ~/.config/taffybar/taffybar.hs > (from taffybar.hs.example in the git repo) but when I run taffybar it says : > > Error occurred while loading configuration file > > When I load the config into ghci it loads without a single warning or > error. Turned out this was not a problem with Taffybar, but rather with with the path to ghc that ghc-paths was providing to Dyre. Github issue raised against ghc-paths here: https://github.com/simonmar/ghc-paths/issues/4 Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/ From mle+hs at mega-nerd.com Mon Jan 13 04:48:17 2014 From: mle+hs at mega-nerd.com (Erik de Castro Lopo) Date: Mon, 13 Jan 2014 15:48:17 +1100 Subject: [xmonad] Compiling xmobar or taffybar into xmonad Message-ID: <20140113154817.f6e4ea9bda0c6b40718e6f09@mega-nerd.com> Hi all, I'm curious if anybody has compiled xmobar or taffybar into their actual actual xmonad. Is this a crazy idea? Cheers, Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/ From allbery.b at gmail.com Mon Jan 13 04:56:36 2014 From: allbery.b at gmail.com (Brandon Allbery) Date: Sun, 12 Jan 2014 23:56:36 -0500 Subject: [xmonad] Compiling xmobar or taffybar into xmonad In-Reply-To: <20140113154817.f6e4ea9bda0c6b40718e6f09@mega-nerd.com> References: <20140113154817.f6e4ea9bda0c6b40718e6f09@mega-nerd.com> Message-ID: On Sun, Jan 12, 2014 at 11:48 PM, Erik de Castro Lopo wrote: > I'm curious if anybody has compiled xmobar or taffybar into their actual > actual xmonad. Is this a crazy idea? > It's a very bad idea without rearchitecting xmonad's main loop to allow it to support anything other than X11 events. In particular, you really want timed events for a status bar, and at present the only way to get that while maintaining access to xmonad's internal state is to have a separate thread periodically sendMessage X11 events to the main thread. -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From mle+hs at mega-nerd.com Mon Jan 13 07:07:02 2014 From: mle+hs at mega-nerd.com (Erik de Castro Lopo) Date: Mon, 13 Jan 2014 18:07:02 +1100 Subject: [xmonad] Compiling xmobar or taffybar into xmonad In-Reply-To: References: <20140113154817.f6e4ea9bda0c6b40718e6f09@mega-nerd.com> Message-ID: <20140113180702.9e3da9e5fe831bf771659b06@mega-nerd.com> Brandon Allbery wrote: > It's a very bad idea without rearchitecting xmonad's main loop to allow it > to support anything other than X11 events. In particular, you really want > timed events for a status bar, and at present the only way to get that > while maintaining access to xmonad's internal state is to have a separate > thread periodically sendMessage X11 events to the main thread. Oh wow, I wasn't going to do anything clever, I was just going to forkIO what would normally have been the main function of taffybar. Taffybar already runs happily in its own process without access to xmonad's internal state, so all it would be doing is using the exising communication protocols and sharing the RTS. Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/ From malikov.d.y at gmail.com Mon Jan 13 07:29:17 2014 From: malikov.d.y at gmail.com (Dmitry Malikov) Date: Mon, 13 Jan 2014 11:29:17 +0400 Subject: [xmonad] Compiling xmobar or taffybar into xmonad In-Reply-To: <20140113154817.f6e4ea9bda0c6b40718e6f09@mega-nerd.com> References: <20140113154817.f6e4ea9bda0c6b40718e6f09@mega-nerd.com> Message-ID: <52D395CD.80606@gmail.com> Hi. You can take a look at xmobar-usable , it is outdated fork of xmobar with ability to have xmobarrc as a pure haskell code. Is that what you want? I.e. here is xmobar.hs that use Application module exported by xmobar-usable. On 01/13/2014 08:48 AM, Erik de Castro Lopo wrote: > Hi all, > > I'm curious if anybody has compiled xmobar or taffybar into their actual > actual xmonad. Is this a crazy idea? > > Cheers, > Erik -- Best regards, dmitry malikov ! -------------- next part -------------- An HTML attachment was scrubbed... URL: From athas at sigkill.dk Mon Jan 13 09:00:59 2014 From: athas at sigkill.dk (Troels Henriksen) Date: Mon, 13 Jan 2014 10:00:59 +0100 Subject: [xmonad] Compiling xmobar or taffybar into xmonad In-Reply-To: <20140113180702.9e3da9e5fe831bf771659b06@mega-nerd.com> (Erik de Castro Lopo's message of "Mon, 13 Jan 2014 18:07:02 +1100") References: <20140113154817.f6e4ea9bda0c6b40718e6f09@mega-nerd.com> <20140113180702.9e3da9e5fe831bf771659b06@mega-nerd.com> Message-ID: <8761pocl2s.fsf@sigkill.dk> Erik de Castro Lopo writes: > Brandon Allbery wrote: > >> It's a very bad idea without rearchitecting xmonad's main loop to allow it >> to support anything other than X11 events. In particular, you really want >> timed events for a status bar, and at present the only way to get that >> while maintaining access to xmonad's internal state is to have a separate >> thread periodically sendMessage X11 events to the main thread. > > Oh wow, I wasn't going to do anything clever, I was just going to forkIO > what would normally have been the main function of taffybar. > > Taffybar already runs happily in its own process without access to xmonad's > internal state, so all it would be doing is using the exising communication > protocols and sharing the RTS. Xlib wasn't reentrant last time I checked, so you'll end up with tons of race conditions. -- \ Troels /\ Henriksen From mle+hs at mega-nerd.com Mon Jan 13 11:40:59 2014 From: mle+hs at mega-nerd.com (Erik de Castro Lopo) Date: Mon, 13 Jan 2014 22:40:59 +1100 Subject: [xmonad] Compiling xmobar or taffybar into xmonad In-Reply-To: <8761pocl2s.fsf@sigkill.dk> References: <20140113154817.f6e4ea9bda0c6b40718e6f09@mega-nerd.com> <20140113180702.9e3da9e5fe831bf771659b06@mega-nerd.com> <8761pocl2s.fsf@sigkill.dk> Message-ID: <20140113224059.bc64d0783333dd9afd5cb643@mega-nerd.com> Troels Henriksen wrote: > Xlib wasn't reentrant last time I checked, so you'll end up with tons of > race conditions. Interestingly, doing what I proposed resulted in an Xmonad where taffybar did not work at all. Rather than try and debug it, I will just blame a non-re-entrant Xlib :-). Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/ From allbery.b at gmail.com Mon Jan 13 14:28:13 2014 From: allbery.b at gmail.com (Brandon Allbery) Date: Mon, 13 Jan 2014 09:28:13 -0500 Subject: [xmonad] Compiling xmobar or taffybar into xmonad In-Reply-To: <20140113180702.9e3da9e5fe831bf771659b06@mega-nerd.com> References: <20140113154817.f6e4ea9bda0c6b40718e6f09@mega-nerd.com> <20140113180702.9e3da9e5fe831bf771659b06@mega-nerd.com> Message-ID: On Mon, Jan 13, 2014 at 2:07 AM, Erik de Castro Lopo wrote: > > It's a very bad idea without rearchitecting xmonad's main loop to allow > it > > to support anything other than X11 events. In particular, you really want > > timed events for a status bar, and at present the only way to get that > > while maintaining access to xmonad's internal state is to have a separate > > thread periodically sendMessage X11 events to the main thread. > > Taffybar already runs happily in its own process without access to xmonad's > internal state, so all it would be doing is using the exising communication > protocols and sharing the RTS. As already noted, Xlib isn't reentrant so this would not work anyway, even if you gave the taffybar thread its own server connection (which would be necessary in any case). There *is* a function that enables Xlib use in a threaded environment, but it works by effectively wrapping all Xlib calls in a big mutex so performance pretty well tanks. In short, it's not worth it. -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From mfwitten at gmail.com Mon Jan 13 18:45:02 2014 From: mfwitten at gmail.com (Michael Witten) Date: Mon, 13 Jan 2014 18:45:02 +0000 Subject: [xmonad] Leak... somewhere... I periodically restart xmonad to recover gobs of swap space Message-ID: Software: xmonad 0.11 xmobar 0.10 Xorg 1.14.1 After a while (say, a month) of normal activity, my swap space becomes almost entirely eaten up; the problem can be solved by restarting xmonad (`mod-q'). The problem could well be `xmobar' or `X' itself. -------------- next part -------------- An HTML attachment was scrubbed... URL: From allbery.b at gmail.com Mon Jan 13 19:08:25 2014 From: allbery.b at gmail.com (Brandon Allbery) Date: Mon, 13 Jan 2014 14:08:25 -0500 Subject: [xmonad] Leak... somewhere... I periodically restart xmonad to recover gobs of swap space In-Reply-To: References: Message-ID: On Mon, Jan 13, 2014 at 1:45 PM, Michael Witten wrote: > After a while (say, a month) of normal activity, my swap space becomes > almost entirely eaten up; the problem can be solved by restarting xmonad > (`mod-q'). > > The problem could well be `xmobar' or `X' itself. > X11 seems unlikely. Memory leaks *are* possible (but unlikely) depending on what you have in your xmonad.hs. (For what it's worth, xmonad isn't even visible on my machine if I sort top by virtual process size. But it's only been running for a couple days thanks to system updates. I don't use xmobar since I run xmonad under xfce.) -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From mfwitten at gmail.com Mon Jan 13 20:35:35 2014 From: mfwitten at gmail.com (Michael Witten) Date: Mon, 13 Jan 2014 20:35:35 +0000 Subject: [xmonad] Leak... somewhere... I periodically restart xmonad to recover gobs of swap space In-Reply-To: References: Message-ID: On Mon, Jan 13, 2014 at 7:08 PM, Brandon Allbery wrote: > On Mon, Jan 13, 2014 at 1:45 PM, Michael Witten wrote: > >> After a while (say, a month) of normal activity, my swap space becomes almost entirely >> eaten up; the problem can be solved by restarting xmonad (`mod-q'). >> >> The problem could well be `xmobar' or `X' itself. > > > X11 seems unlikely. Memory leaks *are* possible (but unlikely) depending on what you > have in your xmonad.hs. > > (For what it's worth, xmonad isn't even visible on my machine if I sort top by virtual process > size. But it's only been running for a couple days thanks to system updates. I don't use xmobar > since I run xmonad under xfce.) Thanks for the input. I'll keep an eye on things; the next time my swap gets suffocated, I'll kill xmobar by itself to see what happens. From allbery.b at gmail.com Mon Jan 13 21:13:14 2014 From: allbery.b at gmail.com (Brandon Allbery) Date: Mon, 13 Jan 2014 16:13:14 -0500 Subject: [xmonad] Leak... somewhere... I periodically restart xmonad to recover gobs of swap space In-Reply-To: References: Message-ID: On Mon, Jan 13, 2014 at 3:35 PM, Michael Witten wrote: > I'll keep an eye on things; the next time my swap gets suffocated, > I'll kill xmobar by itself to see > what happens. > Perhaps use `top`, sorting by virtual size. (X will be large, this is something of a lie because `top` cannot tell the difference between actual memory and mapped video memory.) -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From codesite-noreply at google.com Tue Jan 14 13:20:56 2014 From: codesite-noreply at google.com (codesite-noreply at google.com) Date: Tue, 14 Jan 2014 13:20:56 +0000 Subject: [xmonad] Issue 563 in xmonad: xmonad-contrib build fails on MultiToggle.hs Message-ID: <0-3425899027203913298-4763048127870894210-codesite-noreply=google.com@googlecode.com> Status: New Owner: ---- New issue 563 by Ian... at gmail.com: xmonad-contrib build fails on MultiToggle.hs http://code.google.com/p/xmonad/issues/detail?id=563 What steps will reproduce the problem? 1.cabal install --gobal xmonad-contrib [ 10 of 226] Compiling XMonad.Layout.MultiToggle ( XMonad/Layout/MultiToggle.hs, dist/build/XMonad/Layout/MultiToggle.o ) XMonad/Layout/MultiToggle.hs:162:9: Could not deduce (HList b w0) arising from the ambiguity check for '??' from the context (HList b w) bound by the type signature for (??) :: HList b w => a -> b -> HCons a b at XMonad/Layout/MultiToggle.hs:162:9-42 The type variable 'w0' is ambiguous In the ambiguity check for: forall a b w. HList b w => a -> b -> HCons a b To defer the ambiguity check to use sites, enable AllowAmbiguousTypes In the type signature for '??': (??) :: HList b w => a -> b -> HCons a b Failed to install xmonad-contrib-0.11.2 cabal: Error: some packages failed to install: xmonad-contrib-0.11.2 failed during the building phase. The exception was: ExitFailure 1 What version of the product are you using? On what operating system? Ubuntu 13.10 ghc 7.7.20131127 xmonad-contrib-0.11.2 -- You received this message because this project is configured to send all issue notifications to this address. You may adjust your notification preferences at: https://code.google.com/hosting/settings From codesite-noreply at google.com Tue Jan 14 16:28:17 2014 From: codesite-noreply at google.com (codesite-noreply at google.com) Date: Tue, 14 Jan 2014 16:28:17 +0000 Subject: [xmonad] Issue 563 in xmonad: xmonad-contrib build fails on MultiToggle.hs In-Reply-To: <0-3425899027203913298-4763048127870894210-codesite-noreply=google.com@googlecode.com> References: <0-3425899027203913298-4763048127870894210-codesite-noreply=google.com@googlecode.com> Message-ID: <1-3425899027203913298-4763048127870894210-codesite-noreply=google.com@googlecode.com> Comment #1 on issue 563 by allber... at gmail.com: xmonad-contrib build fails on MultiToggle.hs http://code.google.com/p/xmonad/issues/detail?id=563 We don't really support GHC HEAD, as it changes too rapidly and may have bugs accidentally introduced. If you need to use HEAD, try it with the latest version instead of one from November. -- You received this message because this project is configured to send all issue notifications to this address. You may adjust your notification preferences at: https://code.google.com/hosting/settings From codesite-noreply at google.com Tue Jan 14 16:51:42 2014 From: codesite-noreply at google.com (codesite-noreply at google.com) Date: Tue, 14 Jan 2014 16:51:42 +0000 Subject: [xmonad] Issue 563 in xmonad: xmonad-contrib build fails on MultiToggle.hs In-Reply-To: <1-3425899027203913298-4763048127870894210-codesite-noreply=google.com@googlecode.com> References: <1-3425899027203913298-4763048127870894210-codesite-noreply=google.com@googlecode.com> <0-3425899027203913298-4763048127870894210-codesite-noreply=google.com@googlecode.com> Message-ID: <2-3425899027203913298-4763048127870894210-codesite-noreply=google.com@googlecode.com> Updates: Status: Fixed Comment #2 on issue 563 by vogt.a... at gmail.com: xmonad-contrib build fails on MultiToggle.hs http://code.google.com/p/xmonad/issues/detail?id=563 A newer ghc HEAD isn't going to fix this (rejecting such "ambiguous types" is a feature not a bug). Instead build from darcs, which has a not-so-satisfactory fix, with a command like: cabal install http://code.haskell.org/xmonad/xmonad.tar.gz http://code.haskell.org/XMonadContrib/xmc.tar.gz -- You received this message because this project is configured to send all issue notifications to this address. You may adjust your notification preferences at: https://code.google.com/hosting/settings From codesite-noreply at google.com Tue Jan 14 16:54:33 2014 From: codesite-noreply at google.com (codesite-noreply at google.com) Date: Tue, 14 Jan 2014 16:54:33 +0000 Subject: [xmonad] Issue 563 in xmonad: xmonad-contrib build fails on MultiToggle.hs In-Reply-To: <2-3425899027203913298-4763048127870894210-codesite-noreply=google.com@googlecode.com> References: <2-3425899027203913298-4763048127870894210-codesite-noreply=google.com@googlecode.com> <0-3425899027203913298-4763048127870894210-codesite-noreply=google.com@googlecode.com> Message-ID: <3-3425899027203913298-4763048127870894210-codesite-noreply=google.com@googlecode.com> Comment #3 on issue 563 by allber... at gmail.com: xmonad-contrib build fails on MultiToggle.hs http://code.google.com/p/xmonad/issues/detail?id=563 I didn't want to commit to saying it was a HEAD bug, since I'm not keeping track and it *did* look like it was intended to be a feature; but such bugs have been known to creep in, and there's little point in pursuing further if it's not reproducible in the latest GHC. -- You received this message because this project is configured to send all issue notifications to this address. You may adjust your notification preferences at: https://code.google.com/hosting/settings From daniel at wagner-home.com Tue Jan 14 20:23:57 2014 From: daniel at wagner-home.com (Daniel Wagner) Date: Tue, 14 Jan 2014 15:23:57 -0500 Subject: [xmonad] Leak... somewhere... I periodically restart xmonad to recover gobs of swap space In-Reply-To: References: Message-ID: <0b7dc5f88f341f7c296652de1cacdae0@seas.upenn.edu> Could you include your config file? Perhaps there's something an experienced Haskeller can spot quickly. Then again perhaps not. In any case I have been using xmonad for several years and have not noticed the problem you describe. ~d On 2014-01-13 13:45, Michael Witten wrote: > Software: > > ? xmonad 0.11 > ? xmobar 0.10 > ? Xorg ? 1.14.1 > > ? > > After a while (say, a month) of normal activity, my swap space becomes > almost entirely eaten up; the problem can be solved by restarting > xmonad (`mod-q'). > > The problem could well be `xmobar' or `X' itself. > > _______________________________________________ > xmonad mailing list > xmonad at haskell.org > http://www.haskell.org/mailman/listinfo/xmonad From mfwitten at gmail.com Wed Jan 15 22:03:57 2014 From: mfwitten at gmail.com (Michael Witten) Date: Wed, 15 Jan 2014 22:03:57 -0000 Subject: [xmonad] Leak... somewhere... I periodically restart xmonad to recover gobs of swap space In-Reply-To: <0b7dc5f88f341f7c296652de1cacdae0@seas.upenn.edu> References: <0b7dc5f88f341f7c296652de1cacdae0@seas.upenn.edu> Message-ID: <4d080b1716e84f9fbac463f8ebbf10d9-mfwitten@gmail.com> On Tue, 14 Jan 2014 15:23:57 -0500, Daniel Wagner wrote: >> On 2014-01-13 13:45, Michael Witten wrote: >> >> Software: >> >> xmonad 0.11 >> xmobar 0.10 >> Xorg 1.14.1 >> >> >> After a while (say, a month) of normal activity, my swap space >> becomes almost entirely eaten up; the problem can be solved by >> restarting xmonad (`mod-q'). >> >> The problem could well be `xmobar' or `X' itself. > > Could you include your config file? Perhaps there's something an > experienced Haskeller can spot quickly. Then again perhaps not. In > any case I have been using xmonad for several years and have not > noticed the problem you describe. > ~d ~/.xmonad/xmonad.hs ------------------- import XMonad import XMonad.Hooks.DynamicLog main = xmonad =<< xmobar defaultConfig { modMask = mod4Mask, terminal = "urxvtc" } ~/.xmobarrc ----------- Config { font = "xft:DejaVu Sans Mono:size=9" , bgColor = "black" , fgColor = "grey" , position = Top , lowerOnStart = True , commands = [ Run Cpu ["-L","3","-H","50","--normal","green","--high","red"] 10 , Run Memory ["-t","Mem: %"] 10 , Run Swap [] 10 , Run Network "eth2" [] 10 , Run Date "%a %Y-%m-%d %H:%M:%S" "date" 10 , Run StdinReader ] , sepChar = "%" , alignSep = "}{" , template = "%cpu% | %memory% * %swap% | %eth2% } %StdinReader% { %date%" } From daniel at wagner-home.com Thu Jan 16 16:14:33 2014 From: daniel at wagner-home.com (Daniel Wagner) Date: Thu, 16 Jan 2014 11:14:33 -0500 Subject: [xmonad] Leak... somewhere... I periodically restart xmonad to recover gobs of swap space In-Reply-To: <4d080b1716e84f9fbac463f8ebbf10d9-mfwitten@gmail.com> References: <0b7dc5f88f341f7c296652de1cacdae0@seas.upenn.edu> <4d080b1716e84f9fbac463f8ebbf10d9-mfwitten@gmail.com> Message-ID: On 2014-01-15 17:03, Michael Witten wrote: > On Tue, 14 Jan 2014 15:23:57 -0500, Daniel Wagner wrote: >>> On 2014-01-13 13:45, Michael Witten wrote: >>> After a while (say, a month) of normal activity, my swap space >>> becomes almost entirely eaten up; the problem can be solved by >>> restarting xmonad (`mod-q'). > > ~/.xmonad/xmonad.hs > ------------------- > > import XMonad > import XMonad.Hooks.DynamicLog > > main = xmonad =<< xmobar defaultConfig { modMask = mod4Mask, terminal > = "urxvtc" } ...well, that seems pretty benign. Hard to hide a configuration bug in something that short, so I can see why you think it might be xmonad's fault instead of yours! (And I see from your .xmobarrc that you are also using StdinReader properly, so that's not the problem.) Very strange. ~d From richard at richard-alcock.co.uk Thu Jan 16 18:03:58 2014 From: richard at richard-alcock.co.uk (Richard Alcock) Date: Thu, 16 Jan 2014 18:03:58 +0000 Subject: [xmonad] xmonad Digest, Vol 82, Issue 7 In-Reply-To: References: Message-ID: unsubscribe On 16 January 2014 12:00, wrote: > Send xmonad mailing list submissions to > xmonad at haskell.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://www.haskell.org/mailman/listinfo/xmonad > or, via email, send a message with subject or body 'help' to > xmonad-request at haskell.org > > You can reach the person managing the list at > xmonad-owner at haskell.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of xmonad digest..." > > > Today's Topics: > > 1. Re: Leak... somewhere... I periodically restart xmonad to > recover gobs of swap space (Michael Witten) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 15 Jan 2014 22:03:57 -0000 > From: Michael Witten > To: Daniel Wagner > Cc: xmonad at haskell.org > Subject: Re: [xmonad] Leak... somewhere... I periodically restart > xmonad to recover gobs of swap space > Message-ID: <4d080b1716e84f9fbac463f8ebbf10d9-mfwitten at gmail.com> > > On Tue, 14 Jan 2014 15:23:57 -0500, Daniel Wagner wrote: > > >> On 2014-01-13 13:45, Michael Witten wrote: > >> > >> Software: > >> > >> xmonad 0.11 > >> xmobar 0.10 > >> Xorg 1.14.1 > >> > >> > >> After a while (say, a month) of normal activity, my swap space > >> becomes almost entirely eaten up; the problem can be solved by > >> restarting xmonad (`mod-q'). > >> > >> The problem could well be `xmobar' or `X' itself. > > > > Could you include your config file? Perhaps there's something an > > experienced Haskeller can spot quickly. Then again perhaps not. In > > any case I have been using xmonad for several years and have not > > noticed the problem you describe. > > ~d > > ~/.xmonad/xmonad.hs > ------------------- > > import XMonad > import XMonad.Hooks.DynamicLog > > main = xmonad =<< xmobar defaultConfig { modMask = mod4Mask, terminal = > "urxvtc" } > > ~/.xmobarrc > ----------- > > Config { > font = "xft:DejaVu Sans Mono:size=9" > , bgColor = "black" > , fgColor = "grey" > , position = Top > , lowerOnStart = True > , commands = [ Run Cpu > ["-L","3","-H","50","--normal","green","--high","red"] 10 > , Run Memory ["-t","Mem: %"] 10 > , Run Swap [] 10 > , Run Network "eth2" [] 10 > , Run Date "%a %Y-%m-%d %H:%M:%S" "date" 10 > , Run StdinReader > ] > , sepChar = "%" > , alignSep = "}{" > , template = "%cpu% | %memory% * %swap% | %eth2% } %StdinReader% > { %date%" > } > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > xmonad mailing list > xmonad at haskell.org > http://www.haskell.org/mailman/listinfo/xmonad > > > ------------------------------ > > End of xmonad Digest, Vol 82, Issue 7 > ************************************* > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tyler at plantarum.ca Fri Jan 17 03:41:59 2014 From: tyler at plantarum.ca (Tyler Smith) Date: Thu, 16 Jan 2014 22:41:59 -0500 Subject: [xmonad] dmenu tab completion In-Reply-To: <7a39470b-aa78-4854-9201-1eddcd73ee0e@email.android.com> References: <7a39470b-aa78-4854-9201-1eddcd73ee0e@email.android.com> Message-ID: <52D8A687.2090008@plantarum.ca> Hello, A few notes about the problem I described below. I referred to tab completion in xmobar - of course I should have said dmenu. The problem (dmenu lacking tab completion of any sort) persists, even after completely purging all xmonad and haskell packages from Debian and reinstalling. A similar problem is described here: https://www.linuxquestions.org/questions/slackware-14/dmenu-4175435436/ From the forum post, the problem was resolved, but without any clear suggestions as to how or why. Does anyone have any suggestions on how to fix this? Thanks, Tyler On 10/01/14 06:44 PM, Tyler Smith wrote: > Hello, > > I have been using xmonad for a few weeks. After updating via aptitude > on Debian unstable a few days ago, xmobarno longer offers > tab-completions. It still works, but I have to ype out the whole > command name. The colour of the bar is now black as well. > > I found some discussion of this on a forum. A solution was to rebuild > xmonad. Not knowing Haskell, I'm not sure how to do this. > > Is there another solution? If not, how do I rebuild xmonad - is this > even possible with the Debian package, or do I need to install from > source? > From mathstuf at gmail.com Fri Jan 17 05:18:31 2014 From: mathstuf at gmail.com (Ben Boeckel) Date: Fri, 17 Jan 2014 05:18:31 +0000 (UTC) Subject: [xmonad] Leak... somewhere... I periodically restart xmonad to recover gobs of swap space References: <0b7dc5f88f341f7c296652de1cacdae0@seas.upenn.edu> <4d080b1716e84f9fbac463f8ebbf10d9-mfwitten@gmail.com> Message-ID: On Wed, 15 Jan, 2014 at 22:03:57 GMT, Michael Witten wrote: >>> On 2014-01-13 13:45, Michael Witten wrote: >>> xmobar 0.10 Is there a way to update this? 0.19 is out now. > , Run Swap [] 10 > , Run Network "eth2" [] 10 I use the others and have no problems, so it may be these two. I'd really try to get a newer xmobar first though. --Ben From rdiaz02 at gmail.com Fri Jan 17 10:10:19 2014 From: rdiaz02 at gmail.com (Ramon Diaz-Uriarte) Date: Fri, 17 Jan 2014 11:10:19 +0100 Subject: [xmonad] dmenu tab completion In-Reply-To: <52D8A687.2090008@plantarum.ca> References: <7a39470b-aa78-4854-9201-1eddcd73ee0e@email.android.com> <52D8A687.2090008@plantarum.ca> Message-ID: <8738kmkjg4.fsf@gmail.com> Dear Tyler, On Fri, 17-01-2014, at 04:41, tyler at plantarum.ca wrote: > Hello, > > A few notes about the problem I described below. I referred to tab > completion in xmobar - of course I should have said dmenu. The problem > (dmenu lacking tab completion of any sort) persists, even after > completely purging all xmonad and haskell packages from Debian and > reinstalling. A similar problem is described here: > https://www.linuxquestions.org/questions/slackware-14/dmenu-4175435436/ > > From the forum post, the problem was resolved, but without any clear > suggestions as to how or why. Does anyone have any suggestions on how to > fix this? How are you calling dmenu? I think you might need to use "dmenu_run", NOT just "dmenu" (and this is something that changed sometime in the past). This is what I have now in my xmonad.hs , ((modMask, xK_p ), spawn "dmenu_run") If you change your xmonad.hs you will need to do xmonad --recompile xmonad --restart (That said, I find dmenu is sometimes too slow, and I end up using gmrun and typing the command and completing in there). Best, R. > > Thanks, > > Tyler > > On 10/01/14 06:44 PM, Tyler Smith wrote: >> Hello, >> >> I have been using xmonad for a few weeks. After updating via aptitude >> on Debian unstable a few days ago, xmobarno longer offers >> tab-completions. It still works, but I have to ype out the whole >> command name. The colour of the bar is now black as well. >> >> I found some discussion of this on a forum. A solution was to rebuild >> xmonad. Not knowing Haskell, I'm not sure how to do this. >> >> Is there another solution? If not, how do I rebuild xmonad - is this >> even possible with the Debian package, or do I need to install from >> source? >> > > _______________________________________________ > xmonad mailing list > xmonad at haskell.org > http://www.haskell.org/mailman/listinfo/xmonad -- Ramon Diaz-Uriarte Department of Biochemistry, Lab B-25 Facultad de Medicina Universidad Aut?noma de Madrid Arzobispo Morcillo, 4 28029 Madrid Spain Phone: +34-91-497-2412 Email: rdiaz02 at gmail.com ramon.diaz at iib.uam.es http://ligarto.org/rdiaz From codesite-noreply at google.com Fri Jan 17 10:23:14 2014 From: codesite-noreply at google.com (codesite-noreply at google.com) Date: Fri, 17 Jan 2014 10:23:14 +0000 Subject: [xmonad] Issue 560 in xmonad: Popup (code completion) window disappears In-Reply-To: <1-3425899027203913298-4613746889783310845-codesite-noreply=google.com@googlecode.com> References: <1-3425899027203913298-4613746889783310845-codesite-noreply=google.com@googlecode.com> <0-3425899027203913298-4613746889783310845-codesite-noreply=google.com@googlecode.com> Message-ID: <2-3425899027203913298-4613746889783310845-codesite-noreply=google.com@googlecode.com> Comment #2 on issue 560 by j... at jupiter.dk: Popup (code completion) window disappears http://code.google.com/p/xmonad/issues/detail?id=560 The i3 wm does a better job and configuration is less of a nightmare (java programs just work - no stupid hacks or anything). This bug is a severe showstopper and I am not looking back after switching to i3. -- You received this message because this project is configured to send all issue notifications to this address. You may adjust your notification preferences at: https://code.google.com/hosting/settings From tyler at plantarum.ca Fri Jan 17 13:17:08 2014 From: tyler at plantarum.ca (Tyler Smith) Date: Fri, 17 Jan 2014 08:17:08 -0500 Subject: [xmonad] dmenu tab completion In-Reply-To: <8738kmkjg4.fsf@gmail.com> References: <7a39470b-aa78-4854-9201-1eddcd73ee0e@email.android.com> <52D8A687.2090008@plantarum.ca> <8738kmkjg4.fsf@gmail.com> Message-ID: <52D92D54.7090604@plantarum.ca> On 17/01/14 05:10 AM, Ramon Diaz-Uriarte wrote: >> How are you calling dmenu? I think you might need to use "dmenu_run", NOT just "dmenu" (and this is something that changed sometime in the past). >> This is what I have now in my xmonad.hs , > ((modMask, xK_p ), spawn "dmenu_run") Thanks! I switched from: , ((modm, xK_p ), spawn "exe=`dmenu_path | dmenu` && eval \"exec $exe\"") to , ((modm, xK_p ), spawn "dmenu_run") and dmenu is now working again. > (That said, I find dmenu is sometimes too slow, and I end up using > gmrun and typing the command and completing in there). The original form, when it worked, was fast. Now with dmenu_run it is noticeably slower, so maybe I will switch to gmrun as well. I had been using gmrun under fluxbox, but always found it slow there. Best, Tyler From allbery.b at gmail.com Fri Jan 17 15:07:59 2014 From: allbery.b at gmail.com (Brandon Allbery) Date: Fri, 17 Jan 2014 10:07:59 -0500 Subject: [xmonad] dmenu tab completion In-Reply-To: <52D92D54.7090604@plantarum.ca> References: <7a39470b-aa78-4854-9201-1eddcd73ee0e@email.android.com> <52D8A687.2090008@plantarum.ca> <8738kmkjg4.fsf@gmail.com> <52D92D54.7090604@plantarum.ca> Message-ID: On Fri, Jan 17, 2014 at 8:17 AM, Tyler Smith wrote: > I switched from: > > , ((modm, xK_p ), spawn "exe=`dmenu_path | dmenu` && > eval \"exec $exe\"") > > to > > , ((modm, xK_p ), spawn "dmenu_run") > > and dmenu is now working again. I infer that you have one of those "build up the default from scratch" configs. We have a comment in that example config saying "don't use this as a real config", but various Linux distributions like to remove that comment and recommend its use. If you had not used it, xmonad would probably have handled the dmenu change for you with at most an "xmonad --recompile" needed. This is *why* we disrecommend use of that config --- it hides any changes we make later to xmonad to adapt to changing external utilities, and can hide new functionality. -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From mle+hs at mega-nerd.com Fri Jan 17 23:02:31 2014 From: mle+hs at mega-nerd.com (Erik de Castro Lopo) Date: Sat, 18 Jan 2014 10:02:31 +1100 Subject: [xmonad] xmonad and xhb Message-ID: <20140118100231.c85251a2fa27c66462de9871@mega-nerd.com> Hi all, I have been researching the possibility of porting xmonad to xhb and I have found that it has been discussed numerous times before and that there has even been some experimentation: http://permalink.gmane.org/gmane.comp.lang.haskell.xmonad/13580 but I cannot find any real hard details of how xhb/xmonad would differ from xlib/xmonad. Does anybody have any concrete evidence on this issue? Cheers, Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/ From allbery.b at gmail.com Fri Jan 17 23:09:01 2014 From: allbery.b at gmail.com (Brandon Allbery) Date: Fri, 17 Jan 2014 18:09:01 -0500 Subject: [xmonad] xmonad and xhb In-Reply-To: <20140118100231.c85251a2fa27c66462de9871@mega-nerd.com> References: <20140118100231.c85251a2fa27c66462de9871@mega-nerd.com> Message-ID: On Fri, Jan 17, 2014 at 6:02 PM, Erik de Castro Lopo wrote: > I have been researching the possibility of porting xmonad to xhb and > I have found that it has been discussed numerous times before and > that there has even been some experimentation: > > http://permalink.gmane.org/gmane.comp.lang.haskell.xmonad/13580 > > but I cannot find any real hard details of how xhb/xmonad would differ > from xlib/xmonad. > > Does anybody have any concrete evidence on this issue? > At one point we had a thing from sjanssen (which I thought we had a ticket for, but I couldn't find it last time I looked) saying that he had looked into it and rejected it; he gave no details though, so you might try to track him down for details. (If he even remembers them at this point.) -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From mle+hs at mega-nerd.com Fri Jan 17 23:56:25 2014 From: mle+hs at mega-nerd.com (Erik de Castro Lopo) Date: Sat, 18 Jan 2014 10:56:25 +1100 Subject: [xmonad] xmonad and xhb In-Reply-To: References: <20140118100231.c85251a2fa27c66462de9871@mega-nerd.com> Message-ID: <20140118105625.1016645e6abf874edf1fdf2d@mega-nerd.com> Brandon Allbery wrote: > At one point we had a thing from sjanssen (which I thought we had a ticket > for, but I couldn't find it last time I looked) saying that he had looked > into it and rejected it; he gave no details though, so you might try to > track him down for details. (If he even remembers them at this point.) Does anyone have an email for Spencer as the only ones I can find on the net bounce. Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/ From wirtwolff at gmail.com Sat Jan 18 00:21:07 2014 From: wirtwolff at gmail.com (Wirt Wolff) Date: Fri, 17 Jan 2014 17:21:07 -0700 Subject: [xmonad] Leak... somewhere... I periodically restart xmonad to recover gobs of swap space In-Reply-To: References: <0b7dc5f88f341f7c296652de1cacdae0@seas.upenn.edu> <4d080b1716e84f9fbac463f8ebbf10d9-mfwitten@gmail.com> Message-ID: Sorry I came late to the thread. If I read correctly you're using xmobar 0.10 - there's a rather goofy memory leak due to the allocation of colors in xmobar 0.16 and earlier. So upgrading to a 0.17 or newer xmobar may solve the problem. xmobar release notes: http://projects.haskell.org/xmobar/releases.html regards, vav aka Wirt Wolff On Thu, Jan 16, 2014 at 10:18 PM, Ben Boeckel wrote: > On Wed, 15 Jan, 2014 at 22:03:57 GMT, Michael Witten wrote: > >>> On 2014-01-13 13:45, Michael Witten wrote: > >>> xmobar 0.10 > > Is there a way to update this? 0.19 is out now. > > > , Run Swap [] 10 > > , Run Network "eth2" [] 10 > > I use the others and have no problems, so it may be these two. I'd > really try to get a newer xmobar first though. > > --Ben > > _______________________________________________ > xmonad mailing list > xmonad at haskell.org > http://www.haskell.org/mailman/listinfo/xmonad > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mfwitten at gmail.com Sat Jan 18 03:34:38 2014 From: mfwitten at gmail.com (Michael Witten) Date: Sat, 18 Jan 2014 03:34:38 +0000 Subject: [xmonad] Leak... somewhere... I periodically restart xmonad to recover gobs of swap space In-Reply-To: References: <0b7dc5f88f341f7c296652de1cacdae0@seas.upenn.edu> <4d080b1716e84f9fbac463f8ebbf10d9-mfwitten@gmail.com> Message-ID: On Sat, 2014-Jan-18, Wirt Wolff wrote: > On Thu, Jan 16, 2014 at 10:18 PM, Ben Boeckel wrote: >> >> On Wed, 15 Jan, 2014 at 22:03:57 GMT, Michael Witten wrote: >>> On 2014-01-13 13:45, Michael Witten wrote: >>> xmobar 0.10 >> >> Is there a way to update this? 0.19 is out now. >> >>> , Run Swap [] 10 >>> , Run Network "eth2" [] 10 >> >> I use the others and have no problems, so it may be these two. I'd >> really try to get a newer xmobar first though. > > Sorry I came late to the thread. If I read correctly you're using xmobar > 0.10 - there's a rather goofy memory leak due to the allocation of colors in > xmobar 0.16 and earlier. > > So upgrading to a 0.17 or newer xmobar may solve the problem. > > xmobar release notes: > > http://projects.haskell.org/xmobar/releases.html Thanks for the heads up! That looks like a promising explanation indeed. I'll upgrade presently, and then let the list know how it goes in a month or so. I thank everybody for taking the time to provide input. From wproxym at gmail.com Sat Jan 18 11:33:03 2014 From: wproxym at gmail.com (proxym) Date: Sat, 18 Jan 2014 15:33:03 +0400 Subject: [xmonad] better combineTwoP and Property In-Reply-To: References: <20110408001515.0ec8feb0@proxym> <20110408212613.GA30575@smuckers.uwaterloo.ca> <20110408222655.GA1755@smuckers.uwaterloo.ca> <20110711193817.3881a4f1@proxym> Message-ID: Do you write the fix for combineTwoP now? Now is 2014. I asked earlier in 2011. 2011/7/20 Konstantin Sobolev > Not yet > On Jul 11, 2011 11:38 AM, "??????" wrote: > > ? Fri, 8 Apr 2011 15:41:50 -0700 > > Konstantin Sobolev ?????: > > > >> Hi, > >> > > >> > I agree with your other points. To avoid needing to add an extra > >> > argument to combineTwoP, which breaks configs, you could follow > >> > what is done in XMonad.Layout.MouseResizableTile for setting > >> > draggerType and other parameters. > >> > > >> > > >> Hi > >> > >> Good point. Will try to follow the same pattern, just need a good > >> parameter name > >> > >> combineTwoP {allowEmptyPane = False} x y z w > >> > >> Not promising a quick fix though, a bit busy in the nearest days.. > > > > Did you write the fix? > > > > -- > > Best regards, Mikhail > -------------- next part -------------- An HTML attachment was scrubbed... URL: From codesite-noreply at google.com Sat Jan 18 20:19:36 2014 From: codesite-noreply at google.com (codesite-noreply at google.com) Date: Sat, 18 Jan 2014 20:19:36 +0000 Subject: [xmonad] Issue 557 in xmonad: xmonad grabs keyboard and mouse on focus follows mouse, reproducibly In-Reply-To: <8-3425899027203913298-206832589476730454-codesite-noreply=google.com@googlecode.com> References: <8-3425899027203913298-206832589476730454-codesite-noreply=google.com@googlecode.com> <0-3425899027203913298-206832589476730454-codesite-noreply=google.com@googlecode.com> Message-ID: <9-3425899027203913298-206832589476730454-codesite-noreply=google.com@googlecode.com> Comment #9 on issue 557 by joeyhe... at gmail.com: xmonad grabs keyboard and mouse on focus follows mouse, reproducibly http://code.google.com/p/xmonad/issues/detail?id=557 I reported this bug when I'd just switched to a new laptop. I noticed that over time, the frequency of the bug happening went down. I apparently was doing something when the hardware was new to me, that I stopped doing. Probably fat-fingering its clickpad in some way was causing it to occur early on. Also, using the touch screen it's easy to reproduce the bug, but you need a touch screen (and now I keep mine turned off!) Today, I found another, perhaps better way to reproduce a similar problem. All I need is a single window open in the current workspace. I first press and hold the left Windows key (mod). Then I press and release the right Alt key (this should be identical to clicking mouse button 2, which my laptop does not allow doing in hardware.. I use xkbset to bind right Alt to mouse button 2). Then I release the left Windows key. Unlike the problem initially described, this results in the mouse movement not getting grabbed. Otherwise the behavior is as described: No key presses or mouse clicks (or focus follows mouse) has any effect, until I restart xmonad. For some reason, I can't reproduce that with the stock xmonad configuration. However, I can reproduce it with the default mouseBindings setting. If I install a custom mouseBindings that leaves off the mod-button2 binding, that naturally avoids the problem. (However, clicking on the touch screen can still cause the problem in that configuration.) BTW, I seem to see some flashing of the window border when this bug happens, as if the window lost and regained focus. -- You received this message because this project is configured to send all issue notifications to this address. You may adjust your notification preferences at: https://code.google.com/hosting/settings From ruslan.kiianchuk at gmail.com Sun Jan 19 02:20:02 2014 From: ruslan.kiianchuk at gmail.com (Ruslan Kiianchuk) Date: Sat, 18 Jan 2014 18:20:02 -0800 Subject: [xmonad] Switch to previous workspace layout Message-ID: Hello. Few months ago I became a incredibly happy user of the tiling window manager XMonad. Though I know only the very basics of Haskell, I managed to create a desirable configuration with the help of this postand this perfectly documented config for Ubuntu . Yet I have a question on switching workspace layouts. I'd like the Mod + Shift + Space shortcut to switch to previous workspace instead of the first (default) one. In default config I found only: -- Rotate through the available layout algorithms , ((modm, xK_space ), sendMessage NextLayout) -- Reset the layouts on the current workspace to default , ((modm .|. shiftMask, xK_space ), setLayout $ XMonad.layoutHook conf) Also looking through XMonad.Layout I could find only NextLayout and FirstLayout messages. No PreviousLayout. Is there any straight forward way to implement that? Thank you. -- Sincerely, Ruslan Kiianchuk. -------------- next part -------------- An HTML attachment was scrubbed... URL: From allbery.b at gmail.com Sun Jan 19 02:38:11 2014 From: allbery.b at gmail.com (Brandon Allbery) Date: Sat, 18 Jan 2014 21:38:11 -0500 Subject: [xmonad] Switch to previous workspace layout In-Reply-To: References: Message-ID: On Sat, Jan 18, 2014 at 9:20 PM, Ruslan Kiianchuk < ruslan.kiianchuk at gmail.com> wrote: > Hello. > > Few months ago I became a incredibly happy user of the tiling window > manager XMonad. Though I know only the very basics of Haskell, I managed to > create a desirable configuration with the help of this postand this perfectly documented config > for Ubuntu . > > Yet I have a question on switching workspace layouts. I'd like the Mod + > Shift + Space shortcut to switch to previous workspace instead of the > first (default) one. In default config I found only: > > -- Rotate through the available layout algorithms > , ((modm, xK_space ), sendMessage NextLayout) > > -- Reset the layouts on the current workspace to default > , ((modm .|. shiftMask, xK_space ), setLayout $ XMonad.layoutHook conf) > > > Also looking through XMonad.Layout I could find only NextLayout and > FirstLayout messages. No PreviousLayout. Is there any straight forward > way to implement that? > > Thank you. > > -- > Sincerely, Ruslan Kiianchuk. > > _______________________________________________ > xmonad mailing list > xmonad at haskell.org > http://www.haskell.org/mailman/listinfo/xmonad > > -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From allbery.b at gmail.com Sun Jan 19 02:41:10 2014 From: allbery.b at gmail.com (Brandon Allbery) Date: Sat, 18 Jan 2014 21:41:10 -0500 Subject: [xmonad] Switch to previous workspace layout In-Reply-To: References: Message-ID: On Sat, Jan 18, 2014 at 9:20 PM, Ruslan Kiianchuk < ruslan.kiianchuk at gmail.com> wrote: > Yet I have a question on switching workspace layouts. I'd like the Mod + > Shift + Space shortcut to switch to previous workspace instead of the > first (default) one. In default config I found only: > > -- Rotate through the available layout algorithms > , ((modm, xK_space ), sendMessage NextLayout) > > -- Reset the layouts on the current workspace to default > , ((modm .|. shiftMask, xK_space ), setLayout $ XMonad.layoutHook conf) > > > Also looking through XMonad.Layout I could find only NextLayout and > FirstLayout messages. No PreviousLayout. Is there any straight forward > way to implement that? > The layoutHook is a function; a previous-layout mechanism would involve trying to run that function "backwards". There is unfortunately no way around this. -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From ruslan.kiianchuk at gmail.com Sun Jan 19 02:43:28 2014 From: ruslan.kiianchuk at gmail.com (Ruslan Kiianchuk) Date: Sat, 18 Jan 2014 18:43:28 -0800 Subject: [xmonad] Switch to previous workspace layout In-Reply-To: References: Message-ID: Thanks for the info! That is probably the only thing XMonad can't do :) On Sat, Jan 18, 2014 at 6:41 PM, Brandon Allbery wrote: > On Sat, Jan 18, 2014 at 9:20 PM, Ruslan Kiianchuk < > ruslan.kiianchuk at gmail.com> wrote: > >> Yet I have a question on switching workspace layouts. I'd like the Mod + >> Shift + Space shortcut to switch to previous workspace instead of the >> first (default) one. In default config I found only: >> >> -- Rotate through the available layout algorithms >> , ((modm, xK_space ), sendMessage NextLayout) >> >> -- Reset the layouts on the current workspace to default >> , ((modm .|. shiftMask, xK_space ), setLayout $ XMonad.layoutHook conf) >> >> >> Also looking through XMonad.Layout I could find only NextLayout and >> FirstLayout messages. No PreviousLayout. Is there any straight forward >> way to implement that? >> > > The layoutHook is a function; a previous-layout mechanism would involve > trying to run that function "backwards". There is unfortunately no way > around this. > > -- > brandon s allbery kf8nh sine nomine > associates > allbery.b at gmail.com > ballbery at sinenomine.net > unix, openafs, kerberos, infrastructure, xmonad > http://sinenomine.net > -- Sincerely, Ruslan Kiianchuk. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tyler at plantarum.ca Sun Jan 19 16:15:43 2014 From: tyler at plantarum.ca (Tyler Smith) Date: Sun, 19 Jan 2014 11:15:43 -0500 Subject: [xmonad] dmenu tab completion In-Reply-To: References: <7a39470b-aa78-4854-9201-1eddcd73ee0e@email.android.com> <52D8A687.2090008@plantarum.ca> <8738kmkjg4.fsf@gmail.com> <52D92D54.7090604@plantarum.ca> Message-ID: <473ca533-7942-4e07-8bb6-1c6b8478893f@email.android.com> Thanks, that's good to know. As a newbie, it's very confusing trying to get a basic config set up. There are numerous conflicting examples online. I think I used this one, from the xmonad wiki: http://www.haskell.org/haskellwiki/Xmonad/Config_archive/Template_xmonad.hs_(0.9) It includes the problematic dmenu line. If I'm meant to infer from the comments in that file that it's not suitable as a base xminad.hs, it's not clear to me. There is a line indicating 'normally you'd only override the defaults you're interested in' - which I interpreted as meaning use the file verbatim, and change only lines that you need to. Which is what I did. Perhaps the wording could be clarified? Part of my problem is that Haskell doesn't resemble any language I'm familiar with, so for now anything more involved than changing a key binding requires cutting and pasting from online examples. Thanks, Tyler Brandon Allbery wrote: >On Fri, Jan 17, 2014 at 8:17 AM, Tyler Smith >wrote: > >> I switched from: >> >> , ((modm, xK_p ), spawn "exe=`dmenu_path | >dmenu` && >> eval \"exec $exe\"") >> >> to >> >> , ((modm, xK_p ), spawn "dmenu_run") >> >> and dmenu is now working again. > > >I infer that you have one of those "build up the default from scratch" >configs. We have a comment in that example config saying "don't use >this as >a real config", but various Linux distributions like to remove that >comment >and recommend its use. > >If you had not used it, xmonad would probably have handled the dmenu >change >for you with at most an "xmonad --recompile" needed. This is *why* we >disrecommend use of that config --- it hides any changes we make later >to >xmonad to adapt to changing external utilities, and can hide new >functionality. From rdiaz02 at gmail.com Mon Jan 20 09:51:04 2014 From: rdiaz02 at gmail.com (Ramon Diaz-Uriarte) Date: Mon, 20 Jan 2014 10:51:04 +0100 Subject: [xmonad] dmenu tab completion In-Reply-To: <473ca533-7942-4e07-8bb6-1c6b8478893f@email.android.com> References: <7a39470b-aa78-4854-9201-1eddcd73ee0e@email.android.com> <52D8A687.2090008@plantarum.ca> <8738kmkjg4.fsf@gmail.com> <52D92D54.7090604@plantarum.ca> <473ca533-7942-4e07-8bb6-1c6b8478893f@email.android.com> Message-ID: <87bnz7hth3.fsf@gmail.com> That is exactly my situation; I've been using xmonad for about 4 years, but know no haskell. So early on I created my ~/.xmonad/xmonad.hs, and started cutting and pasting from online examples to change key bindings, etc. R. On Sun, 19-01-2014, at 17:15, tyler at plantarum.ca wrote: > Thanks, that's good to know. > > As a newbie, it's very confusing trying to get a basic config set up. There are numerous conflicting examples online. I think I used this one, from the xmonad wiki: > > http://www.haskell.org/haskellwiki/Xmonad/Config_archive/Template_xmonad.hs_(0.9) > > It includes the problematic dmenu line. If I'm meant to infer from the comments in that file that it's not suitable as a base xminad.hs, it's not clear to me. There is a line indicating 'normally you'd only override the defaults you're interested in' - which I interpreted as meaning use the file verbatim, and change only lines that you need to. Which is what I did. Perhaps the wording could be clarified? > > Part of my problem is that Haskell doesn't resemble any language I'm familiar with, so for now anything more involved than changing a key binding requires cutting and pasting from online examples. > > Thanks, > > Tyler > > Brandon Allbery wrote: >>On Fri, Jan 17, 2014 at 8:17 AM, Tyler Smith >>wrote: >> >>> I switched from: >>> >>> , ((modm, xK_p ), spawn "exe=`dmenu_path | >>dmenu` && >>> eval \"exec $exe\"") >>> >>> to >>> >>> , ((modm, xK_p ), spawn "dmenu_run") >>> >>> and dmenu is now working again. >> >> >>I infer that you have one of those "build up the default from scratch" >>configs. We have a comment in that example config saying "don't use >>this as >>a real config", but various Linux distributions like to remove that >>comment >>and recommend its use. >> >>If you had not used it, xmonad would probably have handled the dmenu >>change >>for you with at most an "xmonad --recompile" needed. This is *why* we >>disrecommend use of that config --- it hides any changes we make later >>to >>xmonad to adapt to changing external utilities, and can hide new >>functionality. -- Ramon Diaz-Uriarte Department of Biochemistry, Lab B-25 Facultad de Medicina Universidad Aut?noma de Madrid Arzobispo Morcillo, 4 28029 Madrid Spain Phone: +34-91-497-2412 Email: rdiaz02 at gmail.com ramon.diaz at iib.uam.es http://ligarto.org/rdiaz From codesite-noreply at google.com Mon Jan 20 15:26:26 2014 From: codesite-noreply at google.com (codesite-noreply at google.com) Date: Mon, 20 Jan 2014 15:26:26 +0000 Subject: [xmonad] Issue 560 in xmonad: Popup (code completion) window disappears In-Reply-To: <2-3425899027203913298-4613746889783310845-codesite-noreply=google.com@googlecode.com> References: <2-3425899027203913298-4613746889783310845-codesite-noreply=google.com@googlecode.com> <0-3425899027203913298-4613746889783310845-codesite-noreply=google.com@googlecode.com> Message-ID: <3-3425899027203913298-4613746889783310845-codesite-noreply=google.com@googlecode.com> Comment #3 on issue 560 by epirea... at gmail.com: Popup (code completion) window disappears http://code.google.com/p/xmonad/issues/detail?id=560 I've got this in my setup as well. It's really annoying.. you can sometimes work-around it by narrowing down the number of matches by typing part of the method name you're hunting for. -> % xmonad --version xmonad 0.11 -> % lsb_release -a LSB Version: 1.4 Distributor ID: Arch Description: Arch Linux Release: rolling Codename: n/a -- You received this message because this project is configured to send all issue notifications to this address. You may adjust your notification preferences at: https://code.google.com/hosting/settings From joe9mail at gmail.com Thu Jan 23 22:33:13 2014 From: joe9mail at gmail.com (Joe M) Date: Thu, 23 Jan 2014 16:33:13 -0600 Subject: [xmonad] Fwd: Re: Patch to XMonad.Actions.CycleRecentWS Message-ID: <20140123223313.GB3464@master> Hello, Please find a patch to XMonad.Actions.CycleRecentWS module of xmonad-contrib. Below is my conversation with the author of the package. Thanks Joe ----- Forwarded message from Micha? Janeczek ----- Date: Tue, 21 Jan 2014 18:56:36 +0100 From: Micha? Janeczek To: Joe M Subject: Re: Patch to XMonad.Actions.CycleRecentWS Hi Joe, I agree it's not a good idea to just crash on bad input :), I only wanted to understand what's going on. I think your patch is a clear improvement in this light. Could you do me a big favor and submit the patch to XMonadContrib mainstream? I actually no longer use xmonad at the moment (trying to implement things I liked the most from my custom configuration as Gnome 3 shell plugins instead), and I don't have the full development environment set up, so this would be probably a bit easier for you. Thanks again for the patch. Best regards, Michal On Tue, Jan 21, 2014 at 5:18 AM, Joe M wrote: > Hello Micha?, > > Thanks for responding. > > > Also, what versions of xmonad and xmonad-contrib do you run? > The latest darcs versions of xmonad and xmonad-contrib. > > > > Also, could you send me your xmonad config? > Please find attached. > > > > >> Thanks for you email. From your XMonad config, are you using the > > >> `cycleRecentWS` function or `cycleWindowSets` with a custom > `genOptions`? > > >> > > >> If it's the standard `cycleRecentWS`, I'm confused how can it get that > > >> far without crashing, I'd think `head (workspaces w)` in `recentTags` > > >> helper function would crash first. Could you add, after importing > > >> Debug.Trace: > > >> > > >> recentTags w = trace (show (workspaces w)) $ map tag $ tail > (workspaces > > >> w) ++ [head (workspaces w)] > > Below is the relevant portion of my xmonad config. > > I get the list of workspaces. But, I filter them out in the below > nonEmptyRecentsOnCurrentScreen to loop only those workspaces that are > on the current screen. There could be hidden workspaces but they might > belong to a different screen. Please let me know if that does not make > sense. > > -- I use mod-tab to start the action, and as soon as mod is > -- released it ends the cycling that is, as long as I am > -- holding down mod I can keep hitting tab to keep cycling > -- back through less recent workspaces > -- so you can hold down mod-shift (or whatever) and hit tab, > -- tab, tab,... whoops I missed the workspace I wanted! ... > -- type ` ... release. > , ((m, xK_Tab), cycleWindowSets nonEmptyRecentsOnCurrentScreen > [xK_space] > xK_Tab > xK_grave) > > -- got this from > -- http://m1.archiveorange.com/ > -- m/att/j8BnA/ArchiveOrange_C872rLadnB1wa3dTcZztmNk4KA8a.hs > > -- Build a list of windowsets with current swapped in turn with each > -- "most recent" workspace as given by nonEmptyTags > nonEmptyRecentsOnCurrentScreen :: > S.StackSet String l a ScreenId sd > -> [S.StackSet String l a ScreenId sd] > nonEmptyRecentsOnCurrentScreen ws = > -- map (S.view `flip` ws) > -- (rotUp . Prelude.filter (\x -> isOnScreen x ws) > -- $ nonEmptyTags ws) > -- map (S.view `flip` ws) (rotUp $ nonEmptyTags ws) > map (S.view `flip` ws) > (rotUp . filterNonCurrentScreenWorkspaces $ nonEmptyTags ws) > where currentScreen = S.screen . S.current $ ws > filterNonCurrentScreenWorkspaces = > Prelude.filter (\x -> fst (unmarshall x) == currentScreen) > -- filterNonCurrentScreenWorkspaces = > -- Prelude.filter (\x -> isOnScreen (S.view x ws) ws) > > -- Given a windowset grab a list of the workspace tags, > -- in the default order > -- current, visibles in screen order, > -- hiddens from most to least recently accessed. > nonEmptyTags :: S.StackSet String l a s sd -> [String] > nonEmptyTags ws = > [ wtag | S.Workspace wtag _ (Just _) <- S.workspaces ws ] > > > > >> , and send me the debug output? > Please let me know if you still want me to send the debug output. > > As my situation is different from normal, I guess you would not > be interested in using the patch. I think it might be good to use the > patch as it adds an error condition anyway. Just my 2 cents. > > Thanks again for your prompt attention, > Joe > ----- End forwarded message ----- -------------- next part -------------- 1 patch for repository http://code.haskell.org/XMonadContrib: Thu Jan 23 16:08:21 CST 2014 joe9mail at gmail.com * fix the "divide by zero" error I have a dual headed monitor setup without any shared workspaces between the screens. In that setup, I see the below errors when I press Tab and I do not have any workspaces with windows on the current screen. keycode 23 sym 65289 ( 0xff09 " Tab ") mask 0x20 (mod3) clean 0x20 (mod3) received sigCHLD keycode 40 sym 101 ( 0x65 " e ") mask 0x20 (mod3) clean 0x20 (mod3) keyreceived sigCHLD code 23 sym 65289 ( 0xff09 " Tab ") mask 0x20 (mod3) clean 0x20 (mod3) keyrceocdeei v2e3d ssyimg C6H5L2D8 9 ( 0xff09 " Tab ") mask 0x20 (mod3) clean 0x20 (mod3) received sigCHLD keycode 59 sym 119 ( 0x77 " w ") mask 0x20 (mod3) clean 0x20 (mod3) keycode 40 sym 101 ( 0x65 " e ") mask 0x20 (mod3) clean 0x20 (mod3) keycode 23 sym 65289 ( 0xff09 " Tab ") mask 0x20 (mod3) clean 0x20 (mod3) divide by zero keycode 108 sym 65513 ( 0xffe9 " Alt_L ") mask 0x0 () clean 0x0 () keycode 59 sym 119 ( 0x77 " w ") mask 0x20 (mod3) clean 0x20 (mod3) keycode 108 sym 65513 ( 0xffe9 " Alt_L ") mask 0x0 () clean 0x0 () keycode 23 sym 65289 ( 0xff09 " Tab ") mask 0x20 (mod3) clean 0x20 (mod3) keycode 23 sym 65289 ( 0xff09 " Tab ") mask 0x20 (mod3) clean 0x20 (mod3) keycodree c2e3i vseydm s6i5g2C8H9L D ( 0xff09 " Tab ") mask 0x20 (mod3) clean 0x20 (mod3) keycode 23 sym 65289 ( 0xff09 " Tab ") mask 0x20 (mod3) clean 0x20 (mod3) keycode 36 sym 65293 ( 0xff0d " Return ") mask 0x20 (mod3) clean 0x20 (mod3) keycode 23 sym 65289 ( 0xff09 " Tab ") mask 0x20 (mod3) clean 0x20 (mod3) keycroedcee i2v3e ds ysmi g6C5H2L8D9 ( 0xff09 " Tab ") mask 0x20 (mod3) clean 0x20 (mod3) divide by zero keycode 65 sym 32 ( 0x20 " space ") mask 0x0 () clean 0x0 () I traced the "divide by zero" message to this line "cycref l i = l !! (i `mod` length l)" of the module XMonad.Actions.CycleRecentWS. New patches: [fix the "divide by zero" error joe9mail at gmail.com**20140123220821 Ignore-this: 437edb5920cd39e99b2f8f89e0fd95bd I have a dual headed monitor setup without any shared workspaces between the screens. In that setup, I see the below errors when I press Tab and I do not have any workspaces with windows on the current screen. keycode 23 sym 65289 ( 0xff09 " Tab ") mask 0x20 (mod3) clean 0x20 (mod3) received sigCHLD keycode 40 sym 101 ( 0x65 " e ") mask 0x20 (mod3) clean 0x20 (mod3) keyreceived sigCHLD code 23 sym 65289 ( 0xff09 " Tab ") mask 0x20 (mod3) clean 0x20 (mod3) keyrceocdeei v2e3d ssyimg C6H5L2D8 9 ( 0xff09 " Tab ") mask 0x20 (mod3) clean 0x20 (mod3) received sigCHLD keycode 59 sym 119 ( 0x77 " w ") mask 0x20 (mod3) clean 0x20 (mod3) keycode 40 sym 101 ( 0x65 " e ") mask 0x20 (mod3) clean 0x20 (mod3) keycode 23 sym 65289 ( 0xff09 " Tab ") mask 0x20 (mod3) clean 0x20 (mod3) divide by zero keycode 108 sym 65513 ( 0xffe9 " Alt_L ") mask 0x0 () clean 0x0 () keycode 59 sym 119 ( 0x77 " w ") mask 0x20 (mod3) clean 0x20 (mod3) keycode 108 sym 65513 ( 0xffe9 " Alt_L ") mask 0x0 () clean 0x0 () keycode 23 sym 65289 ( 0xff09 " Tab ") mask 0x20 (mod3) clean 0x20 (mod3) keycode 23 sym 65289 ( 0xff09 " Tab ") mask 0x20 (mod3) clean 0x20 (mod3) keycodree c2e3i vseydm s6i5g2C8H9L D ( 0xff09 " Tab ") mask 0x20 (mod3) clean 0x20 (mod3) keycode 23 sym 65289 ( 0xff09 " Tab ") mask 0x20 (mod3) clean 0x20 (mod3) keycode 36 sym 65293 ( 0xff0d " Return ") mask 0x20 (mod3) clean 0x20 (mod3) keycode 23 sym 65289 ( 0xff09 " Tab ") mask 0x20 (mod3) clean 0x20 (mod3) keycroedcee i2v3e ds ysmi g6C5H2L8D9 ( 0xff09 " Tab ") mask 0x20 (mod3) clean 0x20 (mod3) divide by zero keycode 65 sym 32 ( 0x20 " space ") mask 0x0 () clean 0x0 () I traced the "divide by zero" message to this line "cycref l i = l !! (i `mod` length l)" of the module XMonad.Actions.CycleRecentWS. ] { hunk ./XMonad/Actions/CycleRecentWS.hs 56 cycref :: [a] -> Int -> a +cycref [] _ = error "XMonad.Actions.CycleRecentWS: no WindowSet to cycle" cycref l i = l !! (i `mod` length l) -- | Cycle through a finite list of WindowSets with repeated presses of a key, while hunk ./XMonad/Actions/CycleRecentWS.hs 71 -> X () cycleWindowSets genOptions mods keyNext keyPrev = do options <- gets $ genOptions . windowset + cycleWindowSetsProcess options mods keyNext keyPrev + +cycleWindowSetsProcess :: [WindowSet] -- ^ List of WindowSets to choose from + -> [KeySym] -- ^ A list of modifier keys used when invoking this action. + -- As soon as one of them is released, the final WindowSet is chosen and the action exits. + -> KeySym -- ^ Key used to preview next WindowSet from the list of generated options + -> KeySym -- ^ Key used to preview previous WindowSet from the list of generated options. + -- If it's the same as nextOption key, it is effectively ignored. + -> X () +cycleWindowSetsProcess [] _ _ _ = return () +cycleWindowSetsProcess options mods keyNext keyPrev = do XConf {theRoot = root, display = d} <- ask let event = allocaXEvent $ \p -> do maskEvent d (keyPressMask .|. keyReleaseMask) p hunk ./XMonad/Actions/CycleRecentWS.hs 95 | t == keyPress && s == keyPrev -> setOption (n-1) | t == keyRelease && s `elem` mods -> return () | otherwise -> setOption n - io $ grabKeyboard d root False grabModeAsync grabModeAsync currentTime + _ <- io $ grabKeyboard d root False grabModeAsync grabModeAsync currentTime setOption 0 io $ ungrabKeyboard d currentTime } Context: [ServerMode properly indent Adam Vogt **20131219201440 Ignore-this: 761b39c3e3c90b6123f068e8b1d34e5d ] [remove ServerMode tabs Adam Vogt **20131219201000 Ignore-this: f21448c248ec0ac289c309ed964ebcff ] [fix -Wall ServerMode Adam Vogt **20131219181030 Ignore-this: 708dd5fc60f43dee3d1da085002052f ] [documentation note that ServerMode is similar to wmctrl Adam Vogt **20131219180748 Ignore-this: 3215bdf1c698c798eca8ed7f62a0f591 ] [Generalized XMonad.Hooks.ServerMode polson2 at hawk.iit.edu**20131216025100 Ignore-this: e58da3b168a1058f32982833ea25a739 ] [IfMax-Layout Ilya Portnov **20131201072634 Ignore-this: dac53f2a0505e740f05fdf03f1db0c21 This adds a new ("conditional") layout, IfMax, which simply runs one layout, if there are <= N windows, and else runs another layout. ] [fix UrgencyHook and add filterUrgencyHook Adam Vogt **20130924224738 Ignore-this: 3b7c62275701e6758397977c5c09b744 ] [export XMonad.Hooks.UrgencyHook.clearUrgency (issue 533) Adam Vogt **20130923031349 Ignore-this: dafe5763d9abcfa606f5c1a8cf5c57d6 ] [minor documentation fix: manageDocks doesn't do anything with struts, so don't claim it does Daniel Wagner **20130814125106 Ignore-this: a2610d6c1318ac0977abfc21d1b91632 ] [don't pretend to be LG3D in X.C.Dmwit because this confuses modern GTK Daniel Wagner **20130813211636 Ignore-this: 8f728dc1b4bf5e472d99419cc5920e51 ] [XMonad.Actions.UpdatePointer: generalise updatePointer Liyang HU **20130730071007 Ignore-this: 3374a62b6c63dcc152dbf843cd0577f0 ] [XMonad.Actions.UpdatePointer: document TowardsCentre Liyang HU **20130730053746 Ignore-this: 2d684b12e4fff0ebec254bea4a4546a3 ] [Haddock formatting in H.Minimize Adam Vogt **20130723155658 Ignore-this: 5db3186a51dec58f78954466ded339cb ] [Bump version (and xmonad dependency) to 0.12 Adam Vogt **20130720205857 Ignore-this: ce165178ca916223501f266339f1de39 This makes a breakage due to missing patches in core a bit more obvious. Previously you would have a build failure regarding some missing identifiers (def re-exported by XMonad from Data.Default), while after applying this patch it will be clear that xmonad-core needs to be updated. ] [Fix issue 551 by also getting manpath without -g flag. Adam Vogt **20130716030536 Ignore-this: ded2d51eb7b7697c0fdfaa8158d612df Instead of taking Ondrej's approach of figuring out which man (man-db or http://primates.ximian.com/~flucifredi/man/) is used by the system, just try both sets of flags. ] [Escape dzen markup and remove xmobar tags from window titles by default. Adam Vogt **20130708144813 Ignore-this: cf56bff752fbf78ea06d5c0cb755f615 The issue was that window titles, such as those set by, for example a browser, could set the window title to display something like normal title Which could be executed by xmobar (or dzen). This adds a ppTitleSanitize which does the above functions. This way when users override ppTitle, the benefits are not lost. Thanks to Ra?l Benencia and Joachim Breitner for bringing this to my attention. ] [DynamicBars-use-ExtensibleState gopsychonauts at gmail.com**20130618074755 Ignore-this: afacba51af2be8ede65b9bcf9b002a7 Hooks.DynamicBars was previously using an MVar and the unsafePerformIO hack ( http://www.haskell.org/haskellwiki/Top_level_mutable_state ) to store bar state. Since ExtensibleState exists to solve these sorts of problems, I've switched the file over to use unsafePerformIO instead. Some functions' types had to be changed to allow access to XState, but the public API is unchanged. ] [Catch exceptions when finding commands on PATH in Prompt.Shell Thomas Tuegel **20130616230219 Ignore-this: 5a4d08c80301864bc14ed784f1054c3f ] [Fix haddock parse error in X.A.LinkWorkspaces Adam Vogt **20130528133448 Ignore-this: 42f05cf8ca9e6d1ffae3bd20666d87ab ] [use Data.Default wherever possible, and deprecate the things it replaces Daniel Wagner **20130528013909 Ignore-this: 898458b1d2868a70dfb09faf473dc7aa ] [eliminate references to defaultConfig Daniel Wagner **20130528005825 Ignore-this: 37ae613e4b943e99c5200915b9d95e58 ] [minimal change needed to get xmonad-contrib to build with xmonad's data-default patch Daniel Wagner **20130528001040 Ignore-this: 291e4f6cd74fc2b808062e0369665170 ] [Remove unneeded XSync call in Layout.ShowWName Francesco Ariis **20130517153341 Ignore-this: 4d107c680572eff464c8f6ed9fabdd41 ] [Remove misleading comment: we definitely don't support ghc-6.6 anymore Adam Vogt **20130514215851 Ignore-this: 2d071cb05709a16763d039222264b426 ] [Fix module name in comment of X.L.Fullscreen Adam Vogt **20130514215727 Ignore-this: cb5cf18c301c5daf5e1a2527da1ef6bf ] [Minor update to cabal file (adding modules & maintainership) Adam Vogt **20130514215632 Ignore-this: 82785e02e544e1f797799bed5b5d9be2 ] [Remove trailing whitespace in X.A.LinkWorkspaces Adam Vogt **20130514215421 Ignore-this: 5015ab4468e7931876eb66b019af804c ] [Update documentation of LinkWorkspaces Module quesel at informatik.uni-oldenburg.de**20110328072813 Ignore-this: da863534931181f551c9c54bc4076c05 ] [Added a module for linking workspaces quesel at informatik.uni-oldenburg.de**20110210165018 Ignore-this: 1dba2164cc3387409873d33099596d91 This module provides a way to link certain workspaces in a multihead setup. That way, when switching to the first one the other heads display the linked workspaces. ] [Cache results from calcGap in ManageDocks Adam Vogt **20130425155811 Ignore-this: e5076fdbdfc68bc159424dd4e0f14456 http://www.haskell.org/pipermail/xmonad/2013-April/013670.html ] [Remove unnecessary contexts from L.MultiToggle Adam Vogt **20130217163356 Ignore-this: 6b0e413d8c3a58f62088c32a96c57c51 ] [Generalises modWorkspace to take any layout-transforming function gopsychonauts at gmail.com**20130501151425 Ignore-this: 28c7dc1f6216bb1ebdffef5434ccbcbd modWorkspace already was capable of modifying the layout with an arbitrary layout -> layout function, but its original type restricted it such that it could only apply a single LayoutModifier; this was often inconvenient, as for example it was not possible simply to compose LayoutModifiers for use with modWorkspace. This patch also reimplements onWorkspaces in terms of modWorkspaces, since with the latter's less restrictive type this is now possible. ] [since XMonad.Config.Dmwit mentions xmobar, we should include the associated .xmobarrc file Daniel Wagner **20130503194055 Ignore-this: 2f6d7536df81eb767262b79b60eb1b86 ] [warning police Daniel Wagner **20130502012700 Ignore-this: ae7412ac77c57492a7ad6c5f8f50b9eb ] [XMonad.Config.Dmwit Daniel Wagner **20130502012132 Ignore-this: 7402161579fd2e191b60a057d955e5ea ] [minor fixes to the haddock markup in X.L.IndependentScreens Daniel Wagner **20130411193849 Ignore-this: b6a139aa43fdb39fc1b86566c0c34c7a ] [add whenCurrentOn to X.L.IndependentScreens Daniel Wagner **20130408225251 Ignore-this: ceea3d391f270abc9ed8e52ce19fb1ac ] [Allow to specify the initial gaps' states in X.L.Gaps Paul Fertser **20130222072232 Ignore-this: 31596d918d0050e36ce3f64f56205a64 ] [should bump X11 dependency, too, to make sure we have getAtomName Daniel Wagner **20130225180527 Ignore-this: 260711f27551f18cc66afeb7b4846b9f ] [getAtomName is now defined in the X11 library Daniel Wagner **20130225180323 Ignore-this: 3b9e17c234679e98752a47c37132ee4e ] [Allow to limit maximum row count in X.Prompt completion window Paul Fertser **20130221122050 Ignore-this: 923656f02996f2de2b1336275392c5f9 On a keyboard-less device (such as a smartphone), where one has to use an on-screen keyboard, the maximum completion window height must be limited to avoid overlapping the keyboard. ] [Note in U.NameActions that xmonad core can list default keys now Adam Vogt **20130217233026 Ignore-this: 937bff636fa88171932d5192fe8e290b ] [Export U.NamedActions.addDescrKeys per evaryont's request. Adam Vogt **20130217232619 Ignore-this: a694a0a3ece70b52fba6e8f688d86344 ] [Add EWMH DEMANDS_ATTENTION support to UrgencyHook. Maarten de Vries **20130212181229 Ignore-this: 5a4b314d137676758fad9ec8f85ce422 Add support for the _NET_WM_STATE_DEMANDS_ATTENTION atom by treating it the same way as the WM_HINTS urgency flag. ] [Unconditionally set _NET_WORKAREA in ManageDocks Adam Vogt **20130117180851 Ignore-this: 9f57e53fba9573d8a92cf153beb7fe7a ] [spawn command when no completion is available (if alwaysHighlight is True); changes commandToComplete in Prompt/Shell to complete the whole word instead of using getLastWord c.lopez at kmels.net**20130209190456 Ignore-this: ca7d354bb301b555b64d5e76e31d10e8 ] [order-unindexed-ws-last matthewhague at zoho.com**20120703222726 Ignore-this: 4af8162ee8b16a60e8fd62fbc915d3c0 Changes the WorkspaceCompare module's comparison by index to put workspaces without an index last (rather than first). ] [SpawnOn modification for issue 523 Adam Vogt **20130114014642 Ignore-this: 703f7dc0f800366b752f0ec1cecb52e5 This moves the function to help clean up the `Spawner' to the ManageHook rather than in functions like spawnOn. Probably it makes no difference, the reason is because there's one manageSpawn function but many different so this way there are less functions to write. ] [Update L.TrackFloating.useTransient example code Adam Vogt **20130112041239 Ignore-this: e4e31cf1db742778c1d59d52fdbeed7a Suggest useTransient goes to the right of trackFloating which is the configuration actually tested. ] [Adapt ideas of issue 306 patch to a new modifier in L.TrackFloating Adam Vogt **20130112035701 Ignore-this: d54d27b71b97144ef0660f910fd464aa ] [Make X.A.CycleWS not rely on hidden WS order Dmitri Iouchtchenko **20130109023328 Ignore-this: 8717a154b33253c5df4e9a0ada4c2c3e ] [Add X.H.WorkspaceHistory Dmitri Iouchtchenko **20130109023307 Ignore-this: c9e7ce33a944facc27481dde52c7cc80 ] [Allow removing arbitrary workspaces Dmitri Iouchtchenko **20121231214343 Ignore-this: 6fce4bd3d0c5337e5122158583138e74 ] [Remove first-hidden restriction from X.A.DynamicWorkspaces.removeWorkspace' Dmitri Iouchtchenko **20121231214148 Ignore-this: 55fb0859e9a5f476a834ecbdb774aac8 ] [Add authorspellings file for `darcs show authors'. Adam Vogt **20130101040031 Ignore-this: c3198072ebc6a71d635bec4d8e2c78fd This authorspellings file includes a couple people who've contributed to xmonad (not XMonadContrib). When people have multiple addresses, the most recent one has been picked. ] [TAG 0.11 Adam Vogt **20130101014231 Ignore-this: 57cf32412fd1ce912811cb7fafe930f5 ] Patch bundle hash: a6191fe1104ba4d74de7654c560d2b1f1a39c038 From sacha404 at gmail.com Tue Jan 28 17:59:04 2014 From: sacha404 at gmail.com (Sacha Sokoloski) Date: Tue, 28 Jan 2014 18:59:04 +0100 Subject: [xmonad] Workspace Switching Woes Message-ID: <52E7EFE8.2070603@gmail.com> Hello, I've got a fairly specific issue which I've seen for example here: https://stackoverflow.com/questions/13498979/remove-border-from-fullscreen-floating-windows-only-xmonad-configuration but I haven't found any solutions. Essentially, I'm using the compton compositor to, amongst other things, fade in and out of windows. I also use smartBorders and smartSpacing to hide the spacing and the borders on singleton windows. The problem is that If I begin from a singleton window, then when I switch workspaces, these 'smart' modifiers no longer detect the singleton window as a singleton, and so redraw the border and spacing before the window has faded. Thus, at the beginning of the fade, the singleton window jumps a few pixes as the border and spacing are applied. This may sound very particular, but it's actually fairly jarring to see, and I'm not able to use smartBorders and smartSpacing in combination with this. Has anyone perhaps solved this problem or could point in the direction of a solution? Thanks for any help, - Sacha Sokoloski From md143rbh7f at gmail.com Wed Jan 29 03:45:54 2014 From: md143rbh7f at gmail.com (md143rbh7f) Date: Tue, 28 Jan 2014 22:45:54 -0500 Subject: [xmonad] Patch to fix dbus-send in XMonad.Config.Gnome Message-ID: * Fix dbus-send call in XMonad.Config.Gnome dbus-send --print-reply=string is invalid, but it was silently ignored until recently: http://cgit.freedesktop.org/dbus/dbus/commit/tools/dbus-send.c?id=c690ee4351f99ed5e629ffcf5f4a2edcd418d103 I've changed XMonad.Config.Gnome to run --print-reply=literal, since that's what the old behavior was. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: gnomeDbus.dpatch Type: application/octet-stream Size: 13192 bytes Desc: not available URL: From joe9mail at gmail.com Wed Jan 29 04:56:53 2014 From: joe9mail at gmail.com (Joe M) Date: Tue, 28 Jan 2014 22:56:53 -0600 Subject: [xmonad] patch to change read to Safe.readNote in XMonad-Layout-IndependentScreens Message-ID: <20140129045653.GE3285@master> Hello, I am attaching a patch changing read to Safe.readNote to provide a better error message in XMonad-Layout-IndependentScreens. It requires adding the Safe dependency to xmonad-contrib. Thanks Joe -------------- next part -------------- 1 patch for repository http://code.haskell.org/XMonadContrib: Tue Jan 28 20:48:14 CST 2014 joe9mail at gmail.com * changed read to readNote in XMonad.Layout.IndependentScreens New patches: [changed read to readNote in XMonad.Layout.IndependentScreens joe9mail at gmail.com**20140129024814 Ignore-this: ef2ea9509accb7963125a90049af0b2f ] { hunk ./XMonad/Layout/IndependentScreens.hs 34 -- for the screen stuff import Control.Applicative((<*), liftA2) import Control.Arrow hiding ((|||)) +import Safe (readNote) import Control.Monad import Data.List (nub, genericLength) import Graphics.X11.Xinerama hunk ./XMonad/Layout/IndependentScreens.hs 99 unmarshallS :: PhysicalWorkspace -> ScreenId unmarshallW :: PhysicalWorkspace -> VirtualWorkspace -unmarshall = ((S . read) *** drop 1) . break (=='_') +unmarshall = + ((S . readNote "XMonad.Layout.IndependentScreens: unmarshall read failed") *** drop 1) . break (=='_') unmarshallS = fst . unmarshall unmarshallW = snd . unmarshall hunk ./xmonad-contrib.cabal 67 old-locale, old-time, process, - random + random, + safe else build-depends: base < 3 } Context: [ServerMode properly indent Adam Vogt **20131219201440 Ignore-this: 761b39c3e3c90b6123f068e8b1d34e5d ] [remove ServerMode tabs Adam Vogt **20131219201000 Ignore-this: f21448c248ec0ac289c309ed964ebcff ] [fix -Wall ServerMode Adam Vogt **20131219181030 Ignore-this: 708dd5fc60f43dee3d1da085002052f ] [documentation note that ServerMode is similar to wmctrl Adam Vogt **20131219180748 Ignore-this: 3215bdf1c698c798eca8ed7f62a0f591 ] [Generalized XMonad.Hooks.ServerMode polson2 at hawk.iit.edu**20131216025100 Ignore-this: e58da3b168a1058f32982833ea25a739 ] [IfMax-Layout Ilya Portnov **20131201072634 Ignore-this: dac53f2a0505e740f05fdf03f1db0c21 This adds a new ("conditional") layout, IfMax, which simply runs one layout, if there are <= N windows, and else runs another layout. ] [fix UrgencyHook and add filterUrgencyHook Adam Vogt **20130924224738 Ignore-this: 3b7c62275701e6758397977c5c09b744 ] [export XMonad.Hooks.UrgencyHook.clearUrgency (issue 533) Adam Vogt **20130923031349 Ignore-this: dafe5763d9abcfa606f5c1a8cf5c57d6 ] [minor documentation fix: manageDocks doesn't do anything with struts, so don't claim it does Daniel Wagner **20130814125106 Ignore-this: a2610d6c1318ac0977abfc21d1b91632 ] [don't pretend to be LG3D in X.C.Dmwit because this confuses modern GTK Daniel Wagner **20130813211636 Ignore-this: 8f728dc1b4bf5e472d99419cc5920e51 ] [XMonad.Actions.UpdatePointer: generalise updatePointer Liyang HU **20130730071007 Ignore-this: 3374a62b6c63dcc152dbf843cd0577f0 ] [XMonad.Actions.UpdatePointer: document TowardsCentre Liyang HU **20130730053746 Ignore-this: 2d684b12e4fff0ebec254bea4a4546a3 ] [Haddock formatting in H.Minimize Adam Vogt **20130723155658 Ignore-this: 5db3186a51dec58f78954466ded339cb ] [Bump version (and xmonad dependency) to 0.12 Adam Vogt **20130720205857 Ignore-this: ce165178ca916223501f266339f1de39 This makes a breakage due to missing patches in core a bit more obvious. Previously you would have a build failure regarding some missing identifiers (def re-exported by XMonad from Data.Default), while after applying this patch it will be clear that xmonad-core needs to be updated. ] [Fix issue 551 by also getting manpath without -g flag. Adam Vogt **20130716030536 Ignore-this: ded2d51eb7b7697c0fdfaa8158d612df Instead of taking Ondrej's approach of figuring out which man (man-db or http://primates.ximian.com/~flucifredi/man/) is used by the system, just try both sets of flags. ] [Escape dzen markup and remove xmobar tags from window titles by default. Adam Vogt **20130708144813 Ignore-this: cf56bff752fbf78ea06d5c0cb755f615 The issue was that window titles, such as those set by, for example a browser, could set the window title to display something like normal title Which could be executed by xmobar (or dzen). This adds a ppTitleSanitize which does the above functions. This way when users override ppTitle, the benefits are not lost. Thanks to Ra?l Benencia and Joachim Breitner for bringing this to my attention. ] [DynamicBars-use-ExtensibleState gopsychonauts at gmail.com**20130618074755 Ignore-this: afacba51af2be8ede65b9bcf9b002a7 Hooks.DynamicBars was previously using an MVar and the unsafePerformIO hack ( http://www.haskell.org/haskellwiki/Top_level_mutable_state ) to store bar state. Since ExtensibleState exists to solve these sorts of problems, I've switched the file over to use unsafePerformIO instead. Some functions' types had to be changed to allow access to XState, but the public API is unchanged. ] [Catch exceptions when finding commands on PATH in Prompt.Shell Thomas Tuegel **20130616230219 Ignore-this: 5a4d08c80301864bc14ed784f1054c3f ] [Fix haddock parse error in X.A.LinkWorkspaces Adam Vogt **20130528133448 Ignore-this: 42f05cf8ca9e6d1ffae3bd20666d87ab ] [use Data.Default wherever possible, and deprecate the things it replaces Daniel Wagner **20130528013909 Ignore-this: 898458b1d2868a70dfb09faf473dc7aa ] [eliminate references to defaultConfig Daniel Wagner **20130528005825 Ignore-this: 37ae613e4b943e99c5200915b9d95e58 ] [minimal change needed to get xmonad-contrib to build with xmonad's data-default patch Daniel Wagner **20130528001040 Ignore-this: 291e4f6cd74fc2b808062e0369665170 ] [Remove unneeded XSync call in Layout.ShowWName Francesco Ariis **20130517153341 Ignore-this: 4d107c680572eff464c8f6ed9fabdd41 ] [Remove misleading comment: we definitely don't support ghc-6.6 anymore Adam Vogt **20130514215851 Ignore-this: 2d071cb05709a16763d039222264b426 ] [Fix module name in comment of X.L.Fullscreen Adam Vogt **20130514215727 Ignore-this: cb5cf18c301c5daf5e1a2527da1ef6bf ] [Minor update to cabal file (adding modules & maintainership) Adam Vogt **20130514215632 Ignore-this: 82785e02e544e1f797799bed5b5d9be2 ] [Remove trailing whitespace in X.A.LinkWorkspaces Adam Vogt **20130514215421 Ignore-this: 5015ab4468e7931876eb66b019af804c ] [Update documentation of LinkWorkspaces Module quesel at informatik.uni-oldenburg.de**20110328072813 Ignore-this: da863534931181f551c9c54bc4076c05 ] [Added a module for linking workspaces quesel at informatik.uni-oldenburg.de**20110210165018 Ignore-this: 1dba2164cc3387409873d33099596d91 This module provides a way to link certain workspaces in a multihead setup. That way, when switching to the first one the other heads display the linked workspaces. ] [Cache results from calcGap in ManageDocks Adam Vogt **20130425155811 Ignore-this: e5076fdbdfc68bc159424dd4e0f14456 http://www.haskell.org/pipermail/xmonad/2013-April/013670.html ] [Remove unnecessary contexts from L.MultiToggle Adam Vogt **20130217163356 Ignore-this: 6b0e413d8c3a58f62088c32a96c57c51 ] [Generalises modWorkspace to take any layout-transforming function gopsychonauts at gmail.com**20130501151425 Ignore-this: 28c7dc1f6216bb1ebdffef5434ccbcbd modWorkspace already was capable of modifying the layout with an arbitrary layout -> layout function, but its original type restricted it such that it could only apply a single LayoutModifier; this was often inconvenient, as for example it was not possible simply to compose LayoutModifiers for use with modWorkspace. This patch also reimplements onWorkspaces in terms of modWorkspaces, since with the latter's less restrictive type this is now possible. ] [since XMonad.Config.Dmwit mentions xmobar, we should include the associated .xmobarrc file Daniel Wagner **20130503194055 Ignore-this: 2f6d7536df81eb767262b79b60eb1b86 ] [warning police Daniel Wagner **20130502012700 Ignore-this: ae7412ac77c57492a7ad6c5f8f50b9eb ] [XMonad.Config.Dmwit Daniel Wagner **20130502012132 Ignore-this: 7402161579fd2e191b60a057d955e5ea ] [minor fixes to the haddock markup in X.L.IndependentScreens Daniel Wagner **20130411193849 Ignore-this: b6a139aa43fdb39fc1b86566c0c34c7a ] [add whenCurrentOn to X.L.IndependentScreens Daniel Wagner **20130408225251 Ignore-this: ceea3d391f270abc9ed8e52ce19fb1ac ] [Allow to specify the initial gaps' states in X.L.Gaps Paul Fertser **20130222072232 Ignore-this: 31596d918d0050e36ce3f64f56205a64 ] [should bump X11 dependency, too, to make sure we have getAtomName Daniel Wagner **20130225180527 Ignore-this: 260711f27551f18cc66afeb7b4846b9f ] [getAtomName is now defined in the X11 library Daniel Wagner **20130225180323 Ignore-this: 3b9e17c234679e98752a47c37132ee4e ] [Allow to limit maximum row count in X.Prompt completion window Paul Fertser **20130221122050 Ignore-this: 923656f02996f2de2b1336275392c5f9 On a keyboard-less device (such as a smartphone), where one has to use an on-screen keyboard, the maximum completion window height must be limited to avoid overlapping the keyboard. ] [Note in U.NameActions that xmonad core can list default keys now Adam Vogt **20130217233026 Ignore-this: 937bff636fa88171932d5192fe8e290b ] [Export U.NamedActions.addDescrKeys per evaryont's request. Adam Vogt **20130217232619 Ignore-this: a694a0a3ece70b52fba6e8f688d86344 ] [Add EWMH DEMANDS_ATTENTION support to UrgencyHook. Maarten de Vries **20130212181229 Ignore-this: 5a4b314d137676758fad9ec8f85ce422 Add support for the _NET_WM_STATE_DEMANDS_ATTENTION atom by treating it the same way as the WM_HINTS urgency flag. ] [Unconditionally set _NET_WORKAREA in ManageDocks Adam Vogt **20130117180851 Ignore-this: 9f57e53fba9573d8a92cf153beb7fe7a ] [spawn command when no completion is available (if alwaysHighlight is True); changes commandToComplete in Prompt/Shell to complete the whole word instead of using getLastWord c.lopez at kmels.net**20130209190456 Ignore-this: ca7d354bb301b555b64d5e76e31d10e8 ] [order-unindexed-ws-last matthewhague at zoho.com**20120703222726 Ignore-this: 4af8162ee8b16a60e8fd62fbc915d3c0 Changes the WorkspaceCompare module's comparison by index to put workspaces without an index last (rather than first). ] [SpawnOn modification for issue 523 Adam Vogt **20130114014642 Ignore-this: 703f7dc0f800366b752f0ec1cecb52e5 This moves the function to help clean up the `Spawner' to the ManageHook rather than in functions like spawnOn. Probably it makes no difference, the reason is because there's one manageSpawn function but many different so this way there are less functions to write. ] [Update L.TrackFloating.useTransient example code Adam Vogt **20130112041239 Ignore-this: e4e31cf1db742778c1d59d52fdbeed7a Suggest useTransient goes to the right of trackFloating which is the configuration actually tested. ] [Adapt ideas of issue 306 patch to a new modifier in L.TrackFloating Adam Vogt **20130112035701 Ignore-this: d54d27b71b97144ef0660f910fd464aa ] [Make X.A.CycleWS not rely on hidden WS order Dmitri Iouchtchenko **20130109023328 Ignore-this: 8717a154b33253c5df4e9a0ada4c2c3e ] [Add X.H.WorkspaceHistory Dmitri Iouchtchenko **20130109023307 Ignore-this: c9e7ce33a944facc27481dde52c7cc80 ] [Allow removing arbitrary workspaces Dmitri Iouchtchenko **20121231214343 Ignore-this: 6fce4bd3d0c5337e5122158583138e74 ] [Remove first-hidden restriction from X.A.DynamicWorkspaces.removeWorkspace' Dmitri Iouchtchenko **20121231214148 Ignore-this: 55fb0859e9a5f476a834ecbdb774aac8 ] [Add authorspellings file for `darcs show authors'. Adam Vogt **20130101040031 Ignore-this: c3198072ebc6a71d635bec4d8e2c78fd This authorspellings file includes a couple people who've contributed to xmonad (not XMonadContrib). When people have multiple addresses, the most recent one has been picked. ] [TAG 0.11 Adam Vogt **20130101014231 Ignore-this: 57cf32412fd1ce912811cb7fafe930f5 ] Patch bundle hash: 77de6f708a4be43650a6755c325fe96a6eb586ec From md143rbh7f at gmail.com Thu Jan 30 20:04:57 2014 From: md143rbh7f at gmail.com (md143rbh7f) Date: Thu, 30 Jan 2014 15:04:57 -0500 Subject: [xmonad] 2013-02-09 change to XMonad.Prompt.Shell breaks shell completion Message-ID: The following change from 2013-02-09 breaks shell completion for me: hunk ./XMonad/Prompt/Shell.hs 65 + commandToComplete _ c = c It seems to be passing the entire string into compgen in order to get the file completions, but it should only pass the last word. I propose reverting this change. Comments are appreciated. (CCing c.lopez at kmels.net, who originally wrote the patch.) -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: shellPromptCompleteLastWord.patch Type: text/x-diff Size: 13144 bytes Desc: not available URL: From vogt.adam at gmail.com Fri Jan 31 02:12:31 2014 From: vogt.adam at gmail.com (adam vogt) Date: Thu, 30 Jan 2014 21:12:31 -0500 Subject: [xmonad] 2013-02-09 change to XMonad.Prompt.Shell breaks shell completion In-Reply-To: References: Message-ID: Hi, Thanks for investigating. Completions are better for my purposes with your proposed change. I am not sure what is different about Carlos L?pez Camey and Carsten Mattner's setups which made that patch "fix" things. Adam On Thu, Jan 30, 2014 at 3:04 PM, md143rbh7f wrote: > The following change from 2013-02-09 breaks shell completion for me: > hunk ./XMonad/Prompt/Shell.hs 65 > + commandToComplete _ c = c > > It seems to be passing the entire string into compgen in order to get the > file completions, but it should only pass the last word. I propose > reverting this change. Comments are appreciated. > > (CCing c.lopez at kmels.net, who originally wrote the patch.) > > _______________________________________________ > xmonad mailing list > xmonad at haskell.org > http://www.haskell.org/mailman/listinfo/xmonad > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From juhp at community.haskell.org Fri Jan 31 07:09:45 2014 From: juhp at community.haskell.org (Jens Petersen) Date: Fri, 31 Jan 2014 16:09:45 +0900 Subject: [xmonad] Bad link on download page In-Reply-To: References: Message-ID: > > On the download page at xmonad.org, > the Fedora link is out of date. Could it please be updated to: https://apps.fedoraproject.org/packages/xmonad Thanks, Jens -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel at wagner-home.com Fri Jan 31 19:55:22 2014 From: daniel at wagner-home.com (Daniel Wagner) Date: Fri, 31 Jan 2014 14:55:22 -0500 Subject: [xmonad] Bad link on download page In-Reply-To: References: Message-ID: I've pushed a fix to the web page repository. Next time the web site synchs with the repository (no more than a day or two) the link should be fixed. ~d On 2014-01-31 02:09, Jens Petersen wrote: >> On the download page at xmonad.org [1], > > the Fedora link is out of date. > Could it please be updated to: > > https://apps.fedoraproject.org/packages/xmonad [2] > > Thanks, Jens > > Links: > ------ > [1] http://xmonad.org > [2] https://apps.fedoraproject.org/packages/xmonad > > _______________________________________________ > xmonad mailing list > xmonad at haskell.org > http://www.haskell.org/mailman/listinfo/xmonad