I believe that the two topics mentioned in the subject of this issue are related and can be solved together. I'm bringing in everyone from issues #8, #7, #56, and #53. Sorry for the spam if you are no longer interested in these issues.

Broadly speaking, there are two main groups of xmonad users:

1. Those who treat xmonad as a window manager with a configuration file. Typically these users have xmonad started by a login manager. In turn, xmonad compiles the configuration file as necessary and then uses exec to replace itself with the binary generated by compiling the configuration file. Some of these users are happy to keep their config files in ~/.xmonad, others would prefer the XDG config directory.

2. Those who treat xmonad as a window manager construction kit. Instead of thinking about their xmonad.hs file as a configuration file, these users build up a set of files, possibly in ~/.xmonad/lib, and possibly using a full cabal project. These users therefore might not want to even use the ~/.xmonad directory or the xmonad binary that comes with the core package.

Of course, every user is going to fall somewhere in between those two groupings. However, I think we can solve all of the issues above if we encourage users to adopt one of the two mentioned groups.

For group 1 we should update Main.hs to first look for xmonad.hs in the XDG configuration directory, and the compiled configuration binary in the XDG data directory. Then fallback to ~/.xmonad. Recent versions of the System.Directory module have support for XDG.

Group 2 is more diverse and complicated. I think this group of users should abandon the xmonad executable and directly use the one generated by compiling their configuration. This means users would have to arrange to have their executable started by their login manager instead of the main xmonad executable, and replace their key binding for xmonad --recompile with a custom script that can build from cabal, stack, whatever. To facilitate this I suggest a new config option to force xmonad to bootstrap itself without execing anything.

Both groups require that any code in xmonad-contrib that reads/writes files to ~/.xmonad be patched to first use XDG directories. Group 1 for obvious reasons, but group 2 as well because they may not even be using ~/.xmonad anymore. If that directory doesn't exist some code in xmonad-contrib will throw an exception.

For transparency, I find myself in group 2. I use ~/.xinitrc to start xmonad directly and would prefer to start my custom xmonad binary instead. I currently build with stack but I'm switching to cabal new-build. I run NixOS and my end goal is to put my custom xmonad binary in the Nix store and not use ~/.xmonad. When I make changes to my .hs files I simply want to nix-build or nix-env and then replace the running xmonad.

Before I work on a PR, I wanted to get feedback. I really do want to unify all of these open issues in a way that will make xmonad flexible enough for all of us. So please add a comment and let me know how far off I am or if this solution would work for you. Thanks.

/cc @siddharthist @sgf-dma @zabbal @zsedem @NeQuissimus @Philonous