Comment #3 on issue 484 by wirtwo...@gmail.com: Use XDG Base Directory Specification http://code.google.com/p/xmonad/issues/detail?id=484 For reference here are links to the previous inconclusive discussion of a patch to implement the XDG_CONFIG_HOME portion of Issue 484. [1] [2] If something like this is to be implemented, a good time would be just after a bug fix release of 0.10. Afterward there would be plenty of time for the news to get out, addressing issues it creates, and adjusting troubleshooting and docs prior to 0.11 (or whatever it's called.) That said, I'm in the camp that isn't yet convinced the benefits outweigh the extra complications. Especially for all the non XDG_CONFIG_HOME files. I consider this a config breaking change, since users would have to move xmonad.hs. Supporting xdg plus ~/.xmonad to avoid breakage doesn't make sense to me. Considering that the main objection to xdg support is increased complexity, adding even more along with additional ambiguity is a bad idea. The way I read the spec, complying would be more involved than what's being proposed. [3] There are two additional directories to support plus a few additional consequences. * Moving non-essential generated files to an xdg cache directory would also need to process lib/ and its subdirectories. Using a cache directory wouldn't by itself prevent the upgrade issues where the old .hi files yield confusing error messages. (These sparked the "delete temporary files" proposals.) Deleting these files once xmonad's done with them might be better than using a new cache directory. Probably xmonad-errors should also go to the cache directory along with .hi, .o but I'm not sure where users would expect it to live since it does give feedback about broken configs. * Another directory $XDG_RUNTIME_DIR should get xmonad-$arch-$os. * $XDG_DATA_HOME should get X.Prompt's .xmonad/history and any similar files. Overall, I think that to sway enough people toward favoring XDG support it's going to take posting compelling use cases illustrating its benefits, along with sustained lobbying over time. [1] http://www.haskell.org/pipermail/xmonad/2008-May/005762.html [2] http://www.haskell.org/pipermail/xmonad/2008-August/006214.html [3] http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html