[xmonad] darcs patch: pass-through-unrecognised-flags

[David McLean]

On Sun, Aug 18, 2013 at 09:58:52PM -0400, adam vogt wrote:
> Is there an advantage to passing information this way over using
> environment variables? Currently this seems to work
> (System.Environment.getEnvironment):
>
> $ ENABLE_FOO=1 xmonad
>
> while your patch would allow contrib code to call
> System.Environment.getArgs to get something out of a very similar
> command line:
>
> $ xmonad --enable-foo=1

Hmm. For "enabling" features, there isn't much of a difference, true.
However, my particular use-case for this change is to extend the xmonad
binary such that it can do things like this:

$ xmonad -c view workspace1
$ xmonad -c nextLayout
$ xmonad -c spawnHere firefox

(I've already implemented a module, basically an extended version of
Hooks.ServerMode, which allows this sort of interaction; I'll probably
throw it into a -contrib patch once this is resolved.)

I suppose that, from a technical point of view, it would *work* equally
well to do this like:

$ COMMAND="view workspace1" xmonad
$ COMMAND=nextLayout xmonad
$ COMMAND="spawnHere firefox" xmonad

But I find such an interface rather clunky and less revealing of the
fact that the xmonad binary will perform an unusual operation, i.e., not
starting XMonad. Allowing for arguments to be passed through enables use
of the former interface instead, which I think is a much better
interface to expose to this functionality.

Thoughts?