ms> Hrvoje's absolutely right. ms> If you guys put random stuff in there, I promise something ms> will break eventually. It does not belong there. Ever. That's a policy decision, which may be a good one. But I don't see any reason why it _must_ break something in packages: the package root directory should _never_ have any _package_ code in it. Packages will be split by directory. Even when we support the flat organization for the .elcs, we don't want them living in the package root directory; many packages have etc/ directories, and there will be an info/ directory. Anything that lives under $HOME is eventually under the control of the user; ~/.xemacs/ is such a natural place for a user to put XEmacs- related personal customizations that we'd better be prepared for random stuff to end up there. Ways to support this include: (1) brute-force: XEmacs-mandated user initialization and custom files go in ~/.xemacs, which doubles as the package root directory. Searching for the init files in that directory is hard-coded into XEmacs, and nothing else that conforms to XEmacs package specs will be searched for there. The locate-* functions are defined to never return "~/.xemacs/" as a directory containing Lisp code. (2) init package: init files live in ~/.xemacs/lisp/init/ or something like that. This is OK for auto-generated files, but users will hate it as a location for init.el. variation: init.el lives somewhere else, and the auto-generated files live in an options package. (3) separate package root: package root is not ~/.xemacs/, but ~/.xemacs/packages.