[xmonad] Re: Patch: improved support for replacing an existing window manager

[Adam Vogt]

* On Monday, October 12 2009, Justin Bogner wrote:

>Adam Vogt <vogt.adam at gmail.com> writes:
>> For reference, I've added to contrib the module XMonad.Util.Replace,
>> which seems to work as well as these core patches, other than the lack
>> of command line flag support (the xmonad binary does not pass flags
>> other than --resume to the ~/.xmonad/xmonad-$arch-$os).
>>
>> Any suggestions for addressing that problem (or the alternative of
>> running `~/.xmonad/xmonad-$arch-$os --replace' instead of
>> /usr/bin/xmonad)
>
>I've thought for quite a while that it would be convenient for xmonad to
>pass any unknown flags on to ~/.xmonad/xmonad-$arch-$os, as that would
>allow for a lot of nice flexibility.
>
>The disadvantage, of course, is that unimplemented flags would probably
>just be ignored, adding a whole new dimension of user errors.
>
>What does everyone else think?

Perhaps a wrapper around the official Main.hs is a cleaner solution:

Those additional flags are passed passed to the xmonad-$arch-$os via an
environment variable, which isn't pretty, but it's more likely to
happen than than adding some kind of --additional-flags flag to core:

] #!/usr/bin/env runghc
] import System.Environment
] import System.Posix.Env (setEnv)
] import System.Process
] import Control.Applicative
] import Data.Maybe
] import Data.List
] 
] main = do
]     xmd <- mapMaybe (listToMaybe . words) . drop 2 . lines
]             <$> readProcess "xmonad" ["--help"] ""
]     x <- getArgs
]     setEnv "XMONAD_EXTRA_ARGS" (unwords $ x \\ xmd) True
]     rawSystem "xmonad" (x `intersect` xmd)

Then the xmonad.hs includes some argument checking on the string from
(getEnv "XMONAD_EXTRA_ARGS").

Some sanity checking is possible here too, either that the args in `x'
are sufficiently far away from the official flags, (by edit distance) or
a comparison against a manually compiled list of contrib flags. But
perhaps Yaakov's suggestion is best:

Using Daniel Schoepe's extensible state patch, we can store a key
containing those additional args, and after each startup hook reads
them, they are removed. A final startupHook complains if any arguments
have not been looked at. I'm not sure whether any more complexity is
necessary to handle flags with the restarts / recompilation that we do.

--
Adam