ms> That's the way the current layout works. It may change. Under what circumstances? The only thing I can imagine that might go there is ... package-init.el! There will be an etc and an info subdirectory, or package subdirectories; the package architecture is inherently hierarchical. Stephen> (1) brute-force: XEmacs-mandated user initialization and Stephen> custom files go in ~/.xemacs, which doubles as the Stephen> package root directory. ms> This is bad, and I'll veto it. Your desire to have the maintainer of the package mechanism own the .xemacs-packages directory lock, stock, and barrel is understood. However, I personally want exactly one XEmacs data-directory in my $HOME, and I really hope it will be named ~/.xemacs. ms> Apart from the fact that I'd be sympathetic to changing the ms> name of ~/.xemacs to ~/.xemacs-packages (now that we've ms> renamed the default late package directory to ms> xemacs-packages), Huh? ms> there's a third solution: ms> (4) Load user init files from anywhere in the load-path. Which currently would put it somewhere under ~/.xemacs, right? So you need to add an init directory to the load path that comes, um, where? This looks like a recipe for revisiting the site-lisp flame-war in slightly different form. This puts the user at risk if for example the default early package directory should be renamed, right? I think _the_ init file should have a known location, not dependent on things that might change with configuration or version changes. The user's other initialization files can be loaded from the path. Have customization be put into a designated file in the user's home directory. That's where, by default, Unix applications stick their customization files anyway. It's not like there'll be an arbitrary proliferation of them. That's a matter of point of view. I certainly hope that XEmacs packages will experience an arbitrary proliferation, many will have their own customization file(s), and I (personally) would like to keep them in $user_xemacs_stuff, whatever its name turns out to be.