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?