April 2009 - xmonad - Haskell.org

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 17 Jan '10

17 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

xmonad-fork
by Gwern Branwen 03 Sep '09

03 Sep '09

I came across this today linked in #darcs: http://physics.oregonstate.edu/~roundyd/codes.php "xmonad-fork xmonad-fork is a modified version of the xmonad window manager that I use. You can get a copy of the source with darcs get http://physics.oregonstate.edu/~roundyd/code/xmonad-fork" 'twould seem Andrea and David have been collaborating extensively on xmonad (by my count, there ~106 patches in this repo not present in core/xmc). Some of them look interesting, but others deal with internals I'm not very familiar with. -- gwern

3 2

darcs patch: man_xmonad.hs: import Data.Monoid for mempty, keybindi...
by Wirt Wolff 02 Jul '09

02 Jul '09

Thu Mar 19 20:46:24 MDT 2009 wirtwolff(a)gmail.com * man_xmonad.hs: import Data.Monoid for mempty, keybinding edits Bring mempty into scope. Add commented ToggleStruts binding. Replace shadowed modMask in keybindings with modm instead.

2 2

Re: [xmonad] submapDefault patch - default action for submaps
by Anders Engström 06 May '09

06 May '09

Hello Stacey and the list since this includes a patch. I could not reproduce the behaviour, but I can clearly see where it fits in. The problem for me is that I cannot currently change the repeat rate (because of a bug in evdev) and my repeat rate is obviously too low for the bug to appear, but that is another issue. The problem is as you stated that ungrab-grab is run between key presses, so I moved the ungrab till after the selected command has been run. This should result in "grab new"-"ungrab old" behaviour and fix your problem, I think, but I haven't actually reproduced the bug so please check if this works and report the success or failure. It all seems to work for me, but I would like some feedback from someone a little bit more experienced than me since I'm rather new to haskell and xmonad myself. First question: It is okay to run grabKeyboard in a nested way like this, right? Second question: I dunno, is it just me, or is grabKeyboard/ungrabKeyboard not defined ANYWHERE? It must come from somewhere... But I could not find it when I tried to follow the import chain. /Anders Engström 2009/4/26 Stacey Sheldon <stac(a)solidgoldbomb.org>: > I'm trying to use the submapDefault functionality that you contributed > to XMonad, and I'm running into a small problem with it. Any assistance > that you can offer on this would be very much appreciated. If there are > any additional details that you require, I'd be happy to provide them. > > [Goal] > > I want to trigger a sticky submap, and then be able to move a floating > window around with the arrow keys. When I hit enter or escape, I want > to return to the normal keybindings. The basic functionality works as > expected so I think I've got the various moving parts connected properly. > > [Problem] > > When I use the arrow keys to move the windows around, I typically hold > down the arrow key until the window ends up in the right position. I've > noticed that some of the repeats of the arrow key are leaking through to > the focused window rather than being captured by the submap. This is > especially noticeable if I switch to using vi keys (h,j,k,l) rather than > the arrow keys to push the floating windows around. I then get a string > of these leaked h's in the focused window. > > I suspect this is caused by the ungrabKeyboard that (I think) happens > between handling one keypress and handling the next (repeating) one. If > the ungrab only occurred once the "exit" key had been pressed, maybe > this problem would go away. > > I'm not a complete haskell noob but I still don't quite have a handle on > how monads work. I have no idea how to fix this. > > [Context] > > I'm fairly certain that the issue that I'm seeing is unrelated to the > particular versions that I'm using but I'll give you the context anyway. > I'm using XMonad 0.8-1 on Ubuntu Intrepid (8.10) as the base > version. I've pulled the definition for submapDefault from the latest > darcs revision into my xmonad.hs file since your patch isn't in the > ubuntu release. > > I'm using submapDefault like this in my xmonad.hs file: > > entersub = submapDefault entersub sublist > sublist = M.fromList $ > [ -- Window floating stuff > ((0, xK_Return), return ()) > , ((0, xK_Escape), return ()) > , ((0, xK_t ), withFocused $ windows . W.sink) > , ((0, xK_Left ), (withFocused > (keysMoveWindow (-20,0))) >> entersub) > , ((0, xK_Right ), (withFocused > (keysMoveWindow (20,0))) >> entersub) > , ((0, xK_Up ), (withFocused > (keysMoveWindow (0,-20))) >> entersub) > , ((0, xK_Down ), (withFocused > (keysMoveWindow (0,20))) >> entersub) > ] > > If you've got the time to look at this, I'd be happy to try any > suggestions for how to fix this. > > Thanks. > > Stacey. >

3 2

darcs patch: NS_Placement (and 1 more)
by konstantin.sobolev＠gmail.com 05 May '09

05 May '09

Tue Apr 28 15:27:31 EDT 2009 konstantin.sobolev(a)gmail.com * NS_Placement Added ability to specify scratchpad manage hooks, mostly for defining window placement in a more flexible manner Tue Apr 28 16:01:36 EDT 2009 konstantin.sobolev(a)gmail.com * ScratchpadRewrite Scratchpad reimplementation in terms of NamedScratchpad. No interface changes.

4 4

Merged functionality from X.L.ThreeColumnsMiddle into X.L.ThreeColumns (and some new features)
by Anders Engström 04 May '09

04 May '09

I had a look at X.L.ThreeColumnsMiddle and X.L.Threecolumns and noticed that they are very similar, actually the first one is based on the second one. Therefore I tried to merge them together and here is the result. This somewhat breaks the configuration syntax, but that is unavoidable. There was a difference in the way column sizes was specified, I adopted the one from the Middle-version since I can't understand why it was done as it was in the original code. I also extended the ability to specify the column size a bit by allowing negative fractions. Negative fractions will specify the size for the slave columns and the behaviour will be different when there are only two windows to manage. Enjoy. /Anders Engström

3 3

darcs patch: U.Loggers: add maildirNew, other loggers, and logger f...
by Wirt Wolff 03 May '09

03 May '09

Sat Apr 11 22:13:56 MDT 2009 wirtwolff(a)gmail.com * U.Loggers: add maildirNew, other loggers, and logger formatting utilities Rework of the Logger portions of patches originally from seanmce33(a)gmail.com to apply without conflicts, plus several formatting utilities for use with X (Maybe String) aka Loggers.

3 2

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