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