August 2015 - xmonad - Haskell.org

google code issues
by Brandon Allbery 27 Jan '16

27 Jan '16

So are we going to do anything about Google Code Issues going away in a little over two weeks? -- brandon s allbery kf8nh sine nomine associates allbery.b(a)gmail.com ballbery(a)sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net

10 18

New release to go with 7.10.2
by Tuncer Ayaz 10 Dec '15

10 Dec '15

Are there any blockers that would prevent cutting a release of current Darcs HEAD to go with the soon to be released GHC 7.10.2? It seems many users install from Darcs anyway, so it appears reasonable to me.

5 14

Using sakura with xmonad
by asjo＠koldfront.dk 21 Nov '15

21 Nov '15

Hi. I recently changed from using xterm to sakura: * https://code.launchpad.net/sakura (primarily because the fonts in xterm look bad when scaled x1.5, and I have to do that on my stationary monitor...) The sakura windows automatically get a thin transparent border with XMonad, through which my desktop background image shows. I would like for this to not happen - as it is distracting. You can see the unwanted effect here: * http://koldfront.dk/misc/xmonad/sakura-xmonad.png compared to what it looks like with xterm: * http://koldfront.dk/misc/xmonad/uxterm-xmonad.png I have tried searching the sakura code and changing random things related to border, rgba, and transparent, but my wild guesses have not been fruitful. Does anyone have any good ideas? I am using running compton (I like the pretty, transparent notifications), in case that matters. OH! I just tried killing compton, and that removed the problem! I guess I should bark up another, uhm, mailing list? Hm, I found this: https://github.com/chjj/compton/issues/139 which is the same problem with another wm, compton, and sakura, and it seems the wm was fixed - so maybe I am in the right place after all? There are some hints here: https://github.com/chjj/compton/issues/240 about what might be the same issue in xmonad. Best regards, Adam -- "Hackers are lazy, in the same way that Adam Sjøgren mathematicians and modernist architects are lazy: asjo(a)koldfront.dk they hate anything extraneous."

3 5

switch workspace on all monitors at once
by Kristopher Keller 29 Oct '15

29 Oct '15

Hi, I'm using three monitors and each monitor has 10 workspaces. This is the code I'm using to switch workspaces: [code] myWorkspaces = withScreens 3 ["1","2","3","4","5","6","7","8","9"] ... [((m .|. modm, k), windows $ onCurrentScreen f i) | (i, k) <- zip (workspaces' conf) [xK_1 .. xK_9] , (f, m) <- [(W.greedyView, 0), (W.shift, shiftMask)]] [/code] I wanted to modify it to add a keybind to switch the workspace on all three monitors at once. For example, control + modm + 2 would switch all monitors to workspace 2. But I'm afraid I don't understand whats going on in that code. Could someone give me a hand? Kristopher

3 2

util/GenerateManpage.hs and latest pandoc
by Joachim Breitner 19 Aug '15

19 Aug '15

Hi, with the latest pandoc, shipped in LTS-3, util/GenerateManpage.hs is broken: ghc util/GenerateManpage.hs [1 of 1] Compiling Main ( util/GenerateManpage.hs, util/GenerateManpage.o ) util/GenerateManpage.hs:45:1: Non type-variable argument in the constraint: RegexContext Regex source1 [[[Char]]] (Use FlexibleContexts to permit this) When checking that `guessKeys' has the inferred type guessKeys :: forall source1. (RegexContext Regex source1 [[[Char]]], RegexContext Regex source1 (String, String, String, [String])) => source1 -> [Char] util/GenerateManpage.hs:84:11: Couldn't match expected type `Pandoc' with actual type `Either Text.Pandoc.Error.PandocError Pandoc' In the second argument of `($)', namely `parsed' In a stmt of a 'do' block: writeFile "./man/xmonad.1" . (manHeader ++) . writeMan (writeOpts {writerStandalone = True, writerTemplate = template}) $ parsed util/GenerateManpage.hs:99:11: Couldn't match expected type `Pandoc' with actual type `Either Text.Pandoc.Error.PandocError Pandoc' In the second argument of `($)', namely `parsed' In a stmt of a 'do' block: writeFile "./man/xmonad.1.html" . writeHtmlString (writeOpts {writerVariables = [("include-before", "<h1>" ++ releaseName ++ "</h1>" ++ "<p>Section: xmonad manual (1)<br/>" ++ "Updated: " ++ releaseDate ++ "</p>" ++ "<hr/>")], writerStandalone = True, writerTemplate = template, writerTableOfContents = True}) $ parsed make: *** [build/xmonad] Error 1 Greetings, Joachim -- Joachim “nomeata” Breitner mail(a)joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata(a)joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nomeata(a)debian.org

1 0

Re: [xmonad] Issue 611 in xmonad: XMonad.Util.Run needs to not encode with recent ghc
by codesite-noreply＠google.com 14 Aug '15

14 Aug '15

Comment #3 on issue 611 by arussell...(a)gmail.com: XMonad.Util.Run needs to not encode with recent ghc https://code.google.com/p/xmonad/issues/detail?id=611 That's intentional. I just used an emoji as an example of a character that is encoded improperly. The issue arises from any multibyte character. -- 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

1 0

Issue 612 in xmonad: XMonad.Core.spawn also double-encodes in recent ghc
by codesite-noreply＠google.com 14 Aug '15

14 Aug '15

Status: New Owner: ---- Labels: Type-Defect New issue 612 by allber...(a)gmail.com: XMonad.Core.spawn also double-encodes in recent ghc https://code.google.com/p/xmonad/issues/detail?id=612 See bug 611. ghc 7.8 and later already encode strings, so we should not. -- 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

1 0

Issue 611 in xmonad: XMonad.Util.Run needs to not encode with recent ghc
by codesite-noreply＠google.com 14 Aug '15

14 Aug '15

Status: New Owner: ---- Labels: Type-Defect New issue 611 by allber...(a)gmail.com: XMonad.Util.Run needs to not encode with recent ghc https://code.google.com/p/xmonad/issues/detail?id=611 ghc 7.8 (I think; certainly 7.10) and later automatically encode strings used as command line parameters. XMonad.Util.Run has encoding code intended for older ghc versions which truncate instead of encoding; this leads to double encoding. -- 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

1 1

Two patches related to XMonad.Prompt
by Norbert Zeh 12 Aug '15

12 Aug '15

Hi folks, I really got used to using emacs ido mode, which offers a pretty powerful and intuitive fuzzy matching of completions, so I wanted to port the same to XMonad.Prompt. This required two patches, included in the attached patch bundles: (1) Completions should be sortable by how well they match the current query string. This turned out to be a very easy addition of a 'sorter' function to XPConfig, which is parameterized by the current query string. The default is 'const id', that is, no sorting is done, which is exactly the old behaviour of XMonad.Prompt. (2) A new module XMonad.Prompt.FuzzyMatch that implements the fuzzy matching. The exact rules for matching and sorting of matches are explained in its documentation. As usual, let me know if anything needs to straightened out before these patches can be applied. Cheers, Norbert

2 4

Re: [xmonad] Issue 526 in xmonad: avoidStruts uses getWindowInfo dpy rootWindow instead of getCleanedScreenInfo
by codesite-noreply＠google.com 11 Aug '15

11 Aug '15

Updates: Summary: avoidStruts uses getWindowInfo dpy rootWindow instead of getCleanedScreenInfo Comment #2 on issue 526 by allber...(a)gmail.com: avoidStruts uses getWindowInfo dpy rootWindow instead of getCleanedScreenInfo https://code.google.com/p/xmonad/issues/detail?id=526 ...and it occurs to me that we can't represent docks on multiple screens properly anyway, since any in the direction of monitor stacking can only be on the ends anyway. (I'm poking at our incorrect _NET_WORKAREA implementation.) I don't think this can be fixed properly. In particular, since EWMH assumes the workspace lives across all monitors, *it* (via strut and _NET_WORKAREA) does not support docks between screens properly. We could still do better than we currently are, but it's going to be a major pain. Also: it has been claimed that the current screen info is from the first Xlib check and not updated by monitor changes. The workaround of using the current bounds of the root window is flat-out wrong, because we *need* to know the boundaries between monitors; some other solution should be found. -- 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

1 4