[xmonad] spawn functions are not unicode safe

[Khudyakov Alexey]

> Well put.  But it would be best to keep Xmonad encoding agnostic.
> Filenames are byte sequences, so spawn should take [Word8] instead of
> [Char].  Otherwise the best it can do is convert [Char] to [Word8] by
> truncating each Char.  Nothing guarrantees that every executable has
> an UTF-8 name, after all, even if the default system locale is UTF-8.
>
It's good thing to keep xmonad encoding agnostic. This is surely out of scope 
of window manager. Making spawn to accept [Word8] instead of String does not 
solve problem. It's just reformulate it and make more obvious. Converting 
[Char] to [Word8] is string encoding ;-). 

> It's better to investigate where the argument of spawn comes from, and
> handle the problem there.  Xlib knows about character encodings, maybe
> we could use its facilities and thus avoid adding further dependencies.

Arguments of spawn can come from anywhere. User input, hardcoded strings 
etc... This sources are far too numerous to handle encoding by themselves. 
As for xlib. AFAIK everything is OK with it. Real problem is standard 
library - putStrLn/executeFile/etc...

Only solution which allow to keep xmonad encoding agnostic and still allows to 
encode strings is to push choice of encoding to user. At least I could not 
imagine anything else. 

I've come up with two possible solutions. 

1. Add encoding field to XConfig. 
> data XConfig l = XConfig { 
>     -- skipped 
>     encoding :: String -> String  -- User supplied encoding
>     }
Downsides - requires to pass config to every function like spawn => change API 
=> break awfully lots of code.

2. Something along lines:
> -- IORef which stores encoding functions. It's value should be set
> -- from user's config and never modified.
> coding :: IO (IORef (String -> String))
> coding = newIORef id
> 
> -- Function to get encoder. Should be the only way to obtain it.
> getEncoder :: IO (String -> String)
> getEncoder = readIORef coding 
> 
> -- putStrLn which works with unicode string (sometimes)
> encodedPutStrLn :: String -> IO ()
> encodedPutStrLn str = do encode <- getEncoder
>                          putStrLn . encode $ str
Upside: break nothing. Only change few functions and provide way to set 
encoding. 
Downside: kludge. 


Comment, suggestions, ideas are welcome.

P.S. I found this in documentation for  XMonad.Util.XSelection. So not only 
spawn affected

    * Unicode handling is busted. But it's still better than calling
      'chr' to translate to ASCII, at least.
      As near as I can tell, the mangling happens when the String is
      outputted somewhere, such as via promptSelection's passing through
      the shell, or GHCi printing to the terminal. utf-string has IO functions
      which can fix this, though I do not know have to use them here. It's
      a complex issue; see
      http://www.haskell.org/pipermail/xmonad/2007-September/001967.html
      http://www.haskell.org/pipermail/xmonad/2007-September/001966.html.