Re: .emacs vs .xemacs vs .xemacs.el vs...?

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. Stephen> That's a policy decision, which may be a good one. But I don't see Stephen> any reason why it _must_ break something in packages: the package root Stephen> directory should _never_ have any _package_ code in it. That's the way the current layout works. It may change. Stephen> (1) brute-force: XEmacs-mandated user initialization and custom files go in Stephen> ~/.xemacs, which doubles as the package root directory. This is bad, and I'll veto it. By default, ~/.xemacs is just another early package. This default, however, can be changed very easily by the user. Thus, under this setup, two things (actually: may or or may not) collide which by design have little or no cohesion and potential interference. Stephen> (2) init package: init files live in ~/.xemacs/lisp/init/ or Stephen> something like that. Stephen> This is OK for auto-generated files, but users will hate it as a Stephen> location for init.el. Stephen> variation: init.el lives somewhere else, and the auto-generated Stephen> files live in an options package. Stephen> (3) separate package root: package root is not ~/.xemacs/, but Stephen> ~/.xemacs/packages. Apart from the fact that I'd be sympathetic to changing the name of ~/.xemacs to ~/.xemacs-packages (now that we've renamed the default late package directory to xemacs-packages), there's a third solution: (4) Load user init files from anywhere in the load-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. Generally, I think we should keep it as in 20.4 for 21.0 and re-open the case for 21.1. -- Cheers =8-} Chipsy Friede, Völkerverständigung und überhaupt blabla