[xmonad] automatically generating template xmonad.hs if it doesn't exist

[Isaac Dupree]

Spencer Janssen wrote:
>> As a user I prefer having the stub config file put there, in 
>> general, because it makes me feel more likely that I've actually got the 
>> right file that's going to be read by the program, and a basic idea of its 
>> syntax.
> 
> I must say I don't understand this.  Do we expect that the user will
> immediately hunt for a file ~/.xmonad/xmonad.hs?  Surely they'll seek the
> documentation first, in which case we can provide solid information on which
> file to edit and how it should look.

you sound entirely right; how do I understand it myself?
- copying from the documentation to a new file is more complicated 
mentally than finding it already there (especially when there isn't an 
obvious complete chunk of text to copy, or file to download)
- there is no immediate feedback about whether putting the file there 
had any effect (maybe the documentation was out of date or for a 
development version? maybe I typo'ed? maybe my configuration had a 
syntax error, or silently did nothing for an entirely idiosyncratic 
reason (like ~/.config/fish/config.fish not propagating the effects of 
`cd` commands to the resulting shell, even though propagating anything 
else works, and even the `cd` there works in other shells.  Luckily it 
was a shell so trying "echo" worked to make sure the config was being 
read in mostly the way I expected.)
- basically it's just because I'm unfamiliar every time with the whole 
configuration system, so every little thing is another thing that could 
go wrong.

 > I mean that we shouldn't create these files if we aren't using them.

Especially don't create ~/.xmonad/xmonad.hs if you're going to ignore 
changes to it as long as no GHC is present, because then I could be very 
confused! Xmonad's log messages may be particularly hard to find since 
they tend to be mixed in with X's startup log messages.  A name like 
~/.xmonad/xmonad.hs.example, with appropriate comments inside (THIS IS 
AN EXAMPLE FILE, REAL CONFIG GOES IN <path>, BUT YOU NEED GHC INSTALLED 
FIRST OR CONFIGURATION WON'T WORK), would probably be quite clear.  Less 
obvious but less wasteful of space would be to install xmonad.hs.example 
in some system directory like /usr/share, and it could be clear to the 
user (if the corresponding xmonad-version is mentioned anywhere, in the 
file-path and/or comments) that it really corresponds to the currently 
installed version of xmonad.

~Isaac