[xmonad] Recommended setup for coding

[Adam Vogt]

* On Saturday, January 23 2010, Quentin Moser wrote:

>If you aren't planning anything large-scale, you can use any XMonad
>install and create
>modules in your ~/.xmonad/lib directory, which is in the search path
>when XMonad compiles your config. So, for example:
..snip..
>There are a number of problems with this simple method though:
>
>* XMonad will recompile _all_ your imported lib/* modules on each
>recompile, so you can't keep too
>  much stuff in there. It will also compile them without optimizations
>to reduce the recompilation time,
>  and Haskell without optimization isn't really that fast anymore.

By default, the keybindings bypass xmonad's recompilation checking. The
reason for such is that users would then have to touch part of their
config to recompile after upgrading xmonad.

You can add a binding that only recompiles what ghc believes is
necessary:

] ,("M-q", spawn $ "ghc -e 'XMonad.recompile False >>= flip Control.Monad.unless System.Exit.exitFailure'"
]                         ++ "&& xmonad --restart")


>* You can't modify current modules in this way (unless you want to
>"overlay" them with a completely
>  new one).

I'll note that errors coming from replacing existing modules can be
confusing if you don't know what to expect:

For example: in contrib A imports U, and A exports some types defined in
B. Then if you make your own copy of U (not A) in ~/.xmonad/lib, and
import both U and A in your config, you can end up with type errors on
arguments you supply to functions from A as:

] Inferred type: U.Type
] Expected type: "xmonad-contrib-0.9":U.Type

Which is solved by also copying A over into ~/.xmonad/lib, which Quentin
already noted.

--
Adam