January 2009 - xmonad

Compile-time verification of keymaps
by Gwern Branwen 28 Mar '10

28 Mar '10

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 So today I edited into my xmonad.hs a binding to the Isohunt.com XMonad.Actions.Search engine for convenience. I naturally chose xK_i for the bound key. When I reloaded, I was surprised to see that mod-i failed to do as it was supposed to. Trying it again, it brought up irssi. That was when I realized mod-i had already been bound in my xmonad.hs, to runOrRaise for irssi, and that the irssi binding happened to be later in the list and so it quietly overwrote the Isohunt binding. After picking a new & unused key, I began reflecting on this. Certainly, this is expected behavior if you're familiar with Data.Map. fromList will do that - a list may have multiple values for a single key (such as xK_i) and the last value wins. But I think in an xmonad.hs, the context is somewhat different. There the semantics are somewhat different. We use 'M.fromList [stuff, more stuff, and the rest]' syntax because Haskell supports list syntax, and it makes life easier on the user to use such a common method. But do we *really* mean to say that it is a sensible thing to bind the same key to multiple contradictory definitions? It just so happens that [xK_i isohunt, xK_i irssi] is equivalent to a destructive update style of 'i = isohunt; i = irssi' when fed through the Map functions. So I thought to myself that maybe there was some static way of specifying a list without duplicates we could use in xmonad.hs. It would be nice to know that one cannot run xmonad.hs with inconsistent sets of bindings*. This checking would, even better, be done at compile-time so one could verify this by simply loading in GHCi (good for everyone who routinely reloads in Emacs or Vim). How to do this? Someone in #haskell suggested extensible records, but that sounds quite difficult. Another approach would be to scrap the static requirement, and simply provide the user a redefined 'fromList' which runs something like 'let x = map fst list in nub x == x' and does something if there are duplicates (calls error, spawns xmessage, etc.) I decided to try a variant of the latter at compile-time, using Template Haskell. I got fairly far with the help of mmorrow, but I didn't actually succeed. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEAREKAAYFAkkgYvgACgkQvpDo5Pfl1oLE3gCgkuHMlUO1+YT4oEFLzhHqmeuB QA4An3X72j1z+StumSOmnTXlTJhHeTft =fBDz -----END PGP SIGNATURE----- The idea is that one should be able to do something like this in xmonad.hs > '{-# LANGUAGE TemplateHaskell #-} > import XMonad.Utils.VerifyKeys > .... > myKeys conf@(XConfig {modMask = m}) = M.fromList $(uniqueTupleListQ [ -- rebind standard actions > ((m .|. shiftMask,xK_p), shellPrompt greenXPConfig) > , ((m, xK_d), raiseBrowser) ] ) VerifyKeys looks something like this: > {-# LANGUAGE TemplateHaskell #-} > module XMonad.Utils.VerifyKeys where > > import Data.List(nub) > import qualified Data.Map > import Language.Haskell.TH.Lib > import Language.Haskell.TH.Syntax > > uniqueTupleListQ :: (Eq a, Lift a, Lift b) => [(a, b)] -> ExpQ > uniqueTupleListQ xs = let ys = map fst xs > ns = nub ys > in case ys == ns of > False -> fail "uniqueTupleListQ: List has conflicting entries." > True -> lift xs The idea is that since we know the keymap at compile-time, we pass it, before it gets turned into a Map (and the relevant information lost), we analyze the list. 'fail' aborts the compilation if the list is bad. You can easily test this out in a different module with some simple expressions: > keymap1, keymap2 :: [(Char, String)] > keymap1 = $(uniqueTupleListQ [('a', "foo"), ('b', "bar")] ) > keymap2 = $(uniqueTupleListQ [('a', "foo"), ('b', "bar"), ('c', "bar"), ('a', "quux")] ) Compiling, this gives us something like this: > [1 of 2] Compiling Tmp ( Tmp.hs, Tmp.o ) > [2 of 2] Compiling Main ( xmonad.hs, xmonad.o ) > Loading package base ... linking ... done. > Loading package array-0.1.0.0 ... linking ... done. > Loading package packedstring-0.1.0.0 ... linking ... done. > Loading package containers-0.1.0.1 ... linking ... done. > Loading package pretty-1.0.0.0 ... linking ... done. > Loading package template-haskell ... linking ... done. > > xmonad.hs:113:12: uniqueTupleListQ: List has conflicting entries. Line 133 is keymap2. If we remove '('a', "quux")', which conflicts with the very first entry, we get: > [1 of 2] Compiling Tmp ( Tmp.hs, Tmp.o ) > [2 of 2] Compiling Main ( xmonad.hs, xmonad.o ) > Loading package base ... linking ... done. > Loading package array-0.1.0.0 ... linking ... done. > Loading package packedstring-0.1.0.0 ... linking ... done. > Loading package containers-0.1.0.1 ... linking ... done. > Loading package pretty-1.0.0.0 ... linking ... done. > Loading package template-haskell ... linking ... done. > Linking foo ... Now, this seems to be exactly what we want, doesn't it? But ultimately I had to admit failure. Template Haskell has a number of restrictions and omissions that make it unfeasible to use. For starters: If we apply uniqueTupleList to an actual keymap (like mine), we discover that uniqueTupleList's constraints are unworkable. Per the type sig, we need 'Lift b', the second half of each tuple in the key list. But XMonad requires b to be a X (), and X () is not instantiated for Lift**. Were it, we would still need Lift instances for Word64 and also CUInt. Lift instances probably wouldn't be too hard to write. The real killer, from an xmonad.hs perspective, is the module restrictions. Fundamentally, one *cannot* use inside a $() anything defined in the same file. {modMask = m}? Nope. greenXPConfig? Nope. 'term = XMonad.terminal conf'? Nope. And so on. It is a minimal set of bindings indeed which only makes use of literals and imported functions. So until Template Haskell improves, that avenue seems to be out. I'm not sure where to go from here. Had Template Haskell worked out, the path would've been easy, a matter of having users make a relatively small modification to their xmonad.hs, and perhaps avoiding entirely TH syntax. Does anyone have a better approach, or is this a foolish thing to want static safety in? ksf suggested that Yi has a combinator approach to keybindings which could solve it, but I am unsure how that works or could be adapted for XMonad.*** * Obviously the consistency is only valuable _in_ a specific Map; if we insisted that all Maps be consistent, then we couldn't override the default Map with our own. ** I may be misinterpreting the type error; possibly we actually need Lift for (X()) *** I'm cc'ing yi-devel since I suspect the topic may be of interest. -- gwern

5 7

darcs patch: Replace custom forever_ with library equivalent
by Daniel Schoepe 27 Mar '10

27 Mar '10

Replaced a custom forever implementation in Main.hsc by the equivalent from the standard libraries. I guess it was legacy code, since forever wasn't in Control.Monad in ghc 6.6 as far as I know. Wed Jan 14 22:55:56 CET 2009 Daniel Schoepe <asgaroth_(a)gmx.de> * Replaced custom forever_ by library function New patches: [Replaced custom forever_ by library function Daniel Schoepe <asgaroth_(a)gmx.de>**20090114215556] { hunk ./XMonad/Main.hsc 146 userCode $ startupHook initxmc -- main loop, for all you HOF/recursion fans out there. - forever_ $ prehandle =<< io (nextEvent dpy e >> getEvent e) + forever $ prehandle =<< io (nextEvent dpy e >> getEvent e) return () where hunk ./XMonad/Main.hsc 150 - forever_ a = a >> forever_ a - -- if the event gives us the position of the pointer, set mousePosition prehandle e = let mouse = do guard (ev_event_type e `elem` evs) return (fromIntegral (ev_x_root e) } Context: [Call logHook as the very last action in windows Spencer Janssen <spencerjanssen(a)gmail.com>**20081209233700 Ignore-this: 4396ad891b607780f8e4b3b6bbce87e ] [Accept inferior crossing events. This patch enables fmouse-focus-follows-screen Spencer Janssen <spencerjanssen(a)gmail.com>**20081205045130 Ignore-this: 3ac329fb92839827aed0a4370784cabd ] [Tile all windows at once Spencer Janssen <spencerjanssen(a)gmail.com>**20081118074447] [Factor rational rect scaling into a separate function Spencer Janssen <spencerjanssen(a)gmail.com>**20081118072849] [Change screen focus by clicking on the root window. Spencer Janssen <spencerjanssen(a)gmail.com>**20081106224031 This is a modification of a patch from Joachim Breitner. ] [Fix #192. Spencer Janssen <spencerjanssen(a)gmail.com>**20081021220059] [select base < 4 for building on ghc 6.10 Adam Vogt <vogt.adam(a)gmail.com>**20081013214509] [add killWindow function Joachim Breitner <mail(a)joachim-breitner.de>**20081005001804 This is required to kill anything that is not focused, without having to focus it first. ] [add'l documentation Devin Mullins <me(a)twifkak.com>**20080927234639] [Regression: ungrab buttons on *non* root windows Spencer Janssen <spencerjanssen(a)gmail.com>**20081007214351] [Partial fix for #40 Spencer Janssen <spencerjanssen(a)gmail.com>**20081007212053 Improvements: - clicking on the root will change focus to that screen - moving the mouse from a window on a screen to an empty screen changes focus to that screen The only remaining issue is that moving the mouse between two empty screens does not change focus. In order to solve this, we'd have to select motion events on the root window, which is potentially expensive. ] [Track mouse position via events received Spencer Janssen <spencerjanssen(a)gmail.com>**20081007203953] [Fix haddock Spencer Janssen <spencerjanssen(a)gmail.com>**20081007094641] [Move screen locating code into pointScreen Spencer Janssen <spencerjanssen(a)gmail.com>**20081007094207] [Make pointWithin a top-level binding Spencer Janssen <spencerjanssen(a)gmail.com>**20081007090229] [sp README, CONFIG, STYLE, TODO gwern0(a)gmail.com**20080913024457] [Use the same X11 dependency as xmonad-contrib Spencer Janssen <spencerjanssen(a)gmail.com>**20080921061508] [Export focusUp' and focusDown' -- work entirely on stacks Spencer Janssen <spencerjanssen(a)gmail.com>**20080911214803] [add W.shiftMaster, fix float/tile-reordering bug Devin Mullins <me(a)twifkak.com>**20080911053909] [TAG 0.8 Spencer Janssen <spencerjanssen(a)gmail.com>**20080905195412] [Spelling. Any bets on how long this has been there? Spencer Janssen <spencerjanssen(a)gmail.com>**20080905195211] [Bump version to 0.8 Spencer Janssen <spencerjanssen(a)gmail.com>**20080905194225] [Remove obsolete comments about darcs X11 Spencer Janssen <spencerjanssen(a)gmail.com>**20080905194915] [Recommend latest packages rather than specific versions Spencer Janssen <spencerjanssen(a)gmail.com>**20080905194837] [Also remove -optl from the executable section Spencer Janssen <spencerjanssen(a)gmail.com>**20080820210023] [-optl-Wl,-s is not needed with recent Cabal versions Spencer Janssen <spencerjanssen(a)gmail.com>**20080820204102] [Haddock links Malebria <malebria(a)riseup.net>**20080601212515] [Haddock syntax for enumeration Malebria <malebria(a)riseup.net>**20080601204951] [I prefer the spencerjanssen(a)gmail.com address now Spencer Janssen <spencerjanssen(a)gmail.com>**20080714202650] [Raise windows in the floating layer when moving or resizing Trevor Elliott <trevor(a)galois.com>**20080521215057] [add currentTag convenience function Devin Mullins <me(a)twifkak.com>**20080511224258] [Make Mirror a newtype Spencer Janssen <sjanssen(a)cse.unl.edu>**20080508104640] [Comments Spencer Janssen <sjanssen(a)cse.unl.edu>**20080507013122] [Break long line Spencer Janssen <sjanssen(a)cse.unl.edu>**20080507012608] [Style Spencer Janssen <sjanssen(a)cse.unl.edu>**20080507012519] [Simplify Spencer Janssen <sjanssen(a)cse.unl.edu>**20080507011309] [Overhaul Choose, fixes issue 183 Spencer Janssen <sjanssen(a)cse.unl.edu>**20080506220809] [Remember if focus changes were caused by mouse actions or by key commands Klaus Weidner <kweidner(a)pobox.com>**20080502175603 If the user used the mouse to change window focus (moving into or clicking on a window), this should be handled differently than focus changes due to keyboard commands. Specifically, it's inappropriate to discard window enter/leave events while the mouse is moving. This fixes the bug where a fast mouse motion across multiple windows resulted in the wrong window keeping focus. It's also helpful information for contrib modules such as UpdatePointer - it's supposed to move the mouse pointer only in response to keyboard actions, not if the user was moving the mouse. ] [Wibble Spencer Janssen <sjanssen(a)cse.unl.edu>**20080506203840] [Added doShift function for more user-friendly hooks Ivan N. Veselov <veselov(a)gmail.com>**20080506185757] [use named colours. fixes startup failure on the XO Don Stewart <dons(a)galois.com>**20080502210149] [Set focus *after* revealing windows Spencer Janssen <sjanssen(a)cse.unl.edu>**20080407222559] [Reveal windows after moving/resizing them. Spencer Janssen <sjanssen(a)cse.unl.edu>**20080407220756 This should reduce the number of repaints for newly visible windows. ] [Hide newly created but non-visible windows (fixes bug #172) Spencer Janssen <sjanssen(a)cse.unl.edu>**20080430014012] [formatting, eta expansion Don Stewart <dons(a)galois.com>**20080418184337] [XMonad.ManageHook: add 'appName', another name for 'resource' Lukas Mai <l.mai(a)web.de>**20080406012006] [XMonad.ManageHook: make 'title' locale-aware; haddock cleanup Lukas Mai <l.mai(a)web.de>**20080406011338 The code for 'title' was stolen from getname.patch (bug #44). ] [XMonad.Main: call setlocale on startup Lukas Mai <l.mai(a)web.de>**20080406011234] [floats always use current screen (with less bugs) robreim(a)bobturf.org**20080405135009] [XMonad.Operations: applySizeHint reshuffle Lukas Mai <l.mai(a)web.de>**20080404215615 Make applySizeHints take window borders into account. Move old functionality to applySizeHintsContents. Add new mkAdjust function that generates a custom autohinter for a window. ] [XMonad.Layout: documentation cleanup Lukas Mai <l.mai(a)web.de>**20080404215444] [Remove gaps from the example config Spencer Janssen <sjanssen(a)cse.unl.edu>**20080329232959] [Remove gaps Spencer Janssen <sjanssen(a)cse.unl.edu>**20080325091526] [TAG 0.7 Spencer Janssen <sjanssen(a)cse.unl.edu>**20080329210249] Patch bundle hash: ef4a14f0e22b06712aac9975c8df956a9b2846ba

7 11

Call for xmonad.hs
by Gwern Branwen 16 Jan '10

16 Jan '10

Hi everyone. So a while ago we were discussing how to improve defaults and what sorts of types and functions XM and XMC could provide which encapsulate common behavior, when Devon asked me what exactly I saw being repeated (besides the 2 or 3 examples I provided), and it occurred to me that I really didn't know. There're ~30 xmonad.hs's here <http://haskell.org/haskellwiki/Xmonad/Config_archive>, but perhaps 1/3 to 1/2 are obsolete or don't compile with darcs XM/XMC (at a very rough guess). I'd like more. So here's what I would greatly appreciate everyone doing: 1) Upload your config 2) If you've uploaded your config, update it! 3) If you use someone else's config, why not mention it? I'd appreciate knowing who's using what, so I can count the popular configurations proportionately* 4) If you don't want to do any of 1-3, perhaps you could email me privately with your config? Thanks in advance all. * I think it's fair to say that if 10 people are using a particular xmonad.hs, and there's a simplification which could be made, that change should count 10x -- gwern ANZUS nuclear Lebed .ch Domination .tm top Amherst USSS Hugo

10 27

patch: New XMonad.Layout.MessageControl module.
by Quentin Moser 03 May '09

03 May '09

Hi, These patches provide a message escape/filtering facility intended to make it easier to control complex nested layouts via messages. The first one provides "unEscape" and "ignore" modifiers you could use to write something like this: > import XMonad.Layout.MessageControl > > myLayout = Full ||| gimp ||| ... > where gimp = ignore NextLayout $ ignore JumpToLayout $ unEscape $ > mastered 0.01 0.2 (simpleTabbed ||| Grid) > > nextOuterLayout = sendMessage NextLayout > nextInnerLayout = sendMessage $ escape NextLayout (see the XMonad.Layout.MessageControl patch for details. For clarification, "ignore" blocks all messages of the _same type_ as its parameter.) However, neither XMonad.Layout.(|||) nor XMonad.Layout.LayoutCombinators.(|||) can be used with this, because they both send messages (NextLayoutNoWrap) which have a private type and therefore cannot be filtered. Thus the patch to X.L.LayoutCombinators, which moves the NoWrap messages from their own type into the JumpLayout type, so that they can now be intercepted with "ignore JumpToLayout". I also made these constructors public because I don't like exporting data types with only part of their constructors, but that's not actually necessary and can be reverted if wanted. ... Also, when adding these modifiers into my Big Monstrous LayoutHook of Hell I had to add an {-# OPTIONS_GHC -fcontext-stack=40 #-} pragma to my xmonad.hs to prevent a context reduction overflow =).

3 2

darcs patch: XMonad.Util.XSelection: update maintainer information
by gwern0＠gmail.com 19 Apr '09

19 Apr '09

Sat Jan 10 16:30:00 EST 2009 gwern0(a)gmail.com * XMonad.Util.XSelection: update maintainer information

3 3

patch: Unicode fix for XMonad.Hooks.EwmhDesktops
by Khudyakov Alexey 19 Mar '09

19 Mar '09

Properly encode destop names before sending them to X server in XMonad.Hooks.EwmhDesktops. XMonadContrib is not buildable without utf8-strings with this patch. Encoding bugs are not limited to spawn functions (-: Sorry for that it's not darcs patch but I have problems with haddock so recording fails.

3 5

darcs patch: UpdatePointer even to empty workspaces (and 1 more)
by Joachim Breitner 19 Mar '09

19 Mar '09

Hi, this is just an update for my patch, now since pointWithin is available from the core Thanks, Joachim Tue Oct 7 10:00:41 CEST 2008 Joachim Breitner <mail(a)joachim-breitner.de> * UpdatePointer even to empty workspaces This makes UpdatePointer more Xinerama-compatible: If the user switches to a screen with an empty workspace, the pointer is moved to that workspace, which I think is expected behavoiur. Wed Oct 8 17:42:45 CEST 2008 Joachim Breitner <mail(a)joachim-breitner.de> * pointWithin has moved to the core

6 6

Extensible programs & defaults: the Gosling Emacs experience
by Gwern Branwen 21 Feb '09

21 Feb '09

So, I happened to be reading a PhD thesis on exokernels, when I came across a reference. The context was that an exokernel is a maximally minimalistic operating system kernel; the kernel solely divides up resources among running programs. The programs get all other abstractions and standard OS services by linking in customized libraries, 'libOSes' as the developers put it. The point was that while an exokernel is designed so that any program can customize the operating system as much as possible, the defaults are still profoundly important, and the authors mentioned an Emacs retrospective which covered that. "UNIX Emacs: A Retrospective. Lessons for Flexible System Design" (by Gosling & Borenstein). I managed to get a copy, and I found some of it very instructive reading. Indeed, I find it instructive to look at various xmonad.hses after reading some excerpts: "The one point on which nearly everyone seems to agree is that the best thing about UNIX Emacs is that mlisp exists. No one even suggested that Emacs would be better without the powerful facility for extension and customization, although it is clear that such facilities, if abused, can create an environment that changes so radically from day to day as to be unusable for most people." "The integration of powerful editing facilities with a full-fledged programming language seems unquestionably useful, though it remains a matter of some debate whether this combination is best achieved by an extension language for a text editor or by implementing the text editor as a subroutine library in an existing programming language." "The key principle is that there is *simple syntax for simple operations*. This does not mean that a more complex syntax should not be available for more complex operations, only that the complexity should not be forced on the programmer in a simple context." "It didn't have to be that way. In the development of Emacs, it was far too easy to say that, since the support for the kind of basic interface was entirely customizable, it wasn't important to devote a lot of attention to getting the default interface to be correct. After all, anyone who didn't like the interface could change it. What this attitude ignored, however, was the old rule our mothers used to teach us about the lasting value of first impressions. Many people tried Emacs, couldn't stand the basic interface, and went back to their old standard editors, such as the vi editor on UNIX." "It is worth noting that this happened despite the fact that several people, independently, implemented more or less complete vi emulation packages for Emacs in mlisp. It seems that even if a package existed that was an absolutely perfect simulation of vi, most of the people who prefer vi to Emacs would stick with the clearly less powerful vi. While this is in part due to the smaller size of vi, it is also attributable to the unacceptable difficulty, in the minds of such people, of having to learn how to turn the vi emulation package on in the first place." "The clear lesson to be learned from this is that, while flexibility in such a system is indeed essential, great care must be paid to get the default behaviours to be simple and natural, and to provide very clear and simple ways to use a carefully chosen small set of the most commonly desired customizations. It may be, organizationally, that the people who build the flexible tools are not necessarily the right people to figure out which are the correct defaults and 'standard options'. The process of making such choices probably requires serious observation of users, or even controlled experiments, to compare possible system configurations." ----- I'm not sure how well XMonad works on the above criteria. It seems to me that there are a number of things which could be improved. For example, one of the most common changes is to switch the modifier from Alt to Win, for the simple reason that stealing Alt renders many programs nearly unusable. The arguments I've seen is that we should follow dwm tradition, and that we have no guarantee that Win is mapped to a real key, but is it really impossible for us to, say, autodetect whether Win is usable and only fallback to Alt? Or perhaps on running XMonad the first time with a xmonad.hs, there could be a prompt. Or... there are many ways we could tackle this issue. Another example: some function usages are copied all over the place. How many configurations have a line that looks like: > , keys = \c -> myKeys c `M.union` keys defaultConfig c Yes, it's neat that we can use basic Data.Map functions to union the default and custom keymaps (with the implication we can be flexible and combine them any other way we like), but it strikes me as wrong to have a relatively opaque task repeated time and again. Why don't we have a helper function such that we could write instead: > , keys = overrideDefaultWith myKeys Or if one is setting ManageHooks. Sure, one *could* write > , className =? "Firefox" --> doF (W.shift "web") 2, 3, 4, 6, or however many different entries one has in one's ManageHooks. But wouldn't a helper function be warranted so one could write: > , shiftClassToWS "Firefox" "web" For that matter, am I the only one who wants to be able to unfloat windows in ManageHook? Leaving aside how there is no actual unfloat function, I was eventually able, thanks to #xmonad, to write in my xmonad.hs: > className =? "defcon.bin.x86" --> ask >>= doF . W.sink But heck, do I understand that? Would someone else have any idea what that means? I mean, we're got 4 operators in there, 3 unusual functions (ask isn't even an xmonad function, it's from the State monad. I think. It seems a little much to expect customizers to understand monads, and the State monad, just to do a basic thing like 'unfloat an application when it opens'). ------ In short, perhaps a goal for 0.9 could be to make customizing XMonad easier on the xmonad.hs level. I think a second goal would be to change defaults in the XMonad core, and to perhaps add in some extensions by default - but that's an entirely other discussion. I'm not sure how people would react if I suggested making SmartBorders the default for the fullscreen layout. :) -- gwern Echelon Herald Islamic VHF CTP BATF POCSAG MDA USCG burhop

3 3

U.Run.runProcessWithInputAndWait exceptions, dzenWithArgs
by wirtwolff 20 Feb '09

20 Feb '09

U.Run.runProcessWithInputAndWait calls waitForProcess and raises exceptions. I probably just should have filed a bug, but figured it's probably a quick fix for a real programmer, and byorgey seems to be on a contrib-patching extravaganza, so: http://www.moonpatio.com:8080/fastcgi/hpaste.fcgi/view?id=999 This mainly affects Hooks.UrgencyHook, although users may be using the dzenWithArgs functions in xmonad.hs Is is safe to simply remove waitForProcess from Util.Run.runProcessWithInputAndWait? Should dzenWithArgs do timeouts differently? (btw thanks Roman, Byorgey, et. al. for all the recent work) regards, wmw

4 3

darcs patch: Fix possible head []
by Joachim Breitner 20 Feb '09

20 Feb '09

Hi, there are not many places where head is used in xmonad, but this is one of them. Time to make it safe. Greetings, Joachim Tue Jan 6 20:20:26 CET 2009 Joachim Breitner <mail(a)joachim-breitner.de> * Fix possible head [] This seems to be a rare case, but I just got hit by it.

4 3