bug#15539: [PATCH] Setting user-emacs-directory

[Mike Carifio]

As the OP approximately six years ago, I neglected to add the "use-case" 
I wanted --user-emacs-directory for, namely to experiment with 
~/.emacs.d/init.el including installing new packages via elpa. I still 
think there's a need, especially as the number of useful packages have 
grown and they can interact. I currently use the "symlink" approach when 
I want to start adding new packages and configurations. It's useful to 
return to a "known good state" if my init.el hacking careens off the 
tracks. Since there was already a _variable_ user-emacs-directory, I 
thought I was just asking to set it early at the command line. It seemed 
to be analogous to --load for an emacs file or --user for another user's 
init file. I didn't realize it had a "read-only" flavor.

Yes, this switch adds another knob, but I happen to think its a useful 
knob and is consistent with --load and --user, both of which allow the 
user to designate a different init file at the command line. Redefining 
HOME at the command line and then "setting it back" inside init.el seems 
convoluted. It could also potentially break site-start.el if some code 
there relied on the right binding of HOME. Admittedly that's a 
farfetched scenario, but not impossible either. Sure would be confusing 
to debug if you didn't know what to look for. All the "do it yourself" 
strategies (other than symlink) also force the user to deeply understand 
the details of the init process, e.g. what switches to throw to override 
various features. So if the criticism is "yet another knob" I would say 
you are pushing people to construct homegrown solutions ... repeatedly.

The XDG patch will let emacs adhere to the XDG desktop conventions and 
you can designate the user-emacs-directory implicitly as well, a 
two-for-one special. Not every platform follows the XDG conventions, but 
I personally mostly use linux, so I'm less concerned with those.