Stephen> However, I personally want exactly one XEmacs data-directory in my Stephen> $HOME, Agreed. Stephen> and I really hope it will be named ~/.xemacs. I don't really care what it's called. The more informative the name the better. 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), Stephen> Huh? I know :-) I haven't documented it yet (next weekend ...), but it works. Try it. ms> there's a third solution: ms> (4) Load user init files from anywhere in the load-path. Stephen> Which currently would put it somewhere under ~/.xemacs, Stephen> right? Yes. Stephen> So you need to add an init directory to the load path No. Stephen> This puts the user at risk if for example the default early package Stephen> directory should be renamed, right? Any change renaming anything puts the user at risk. Stephen> I think _the_ init file should have a known location, not dependent on Stephen> things that might change with configuration or version Stephen> changes. I agree, but I wouldn't cry if it turned out different. Stephen> That's a matter of point of view. I certainly hope that Stephen> XEmacs packages will experience an arbitrary proliferation, Well, in that sense, we already have: .newsrc.eld, .vm etc. etc. etc. I didn't think about this before, but this, I think, underlines that we should wait until 21.1 to solve all of these problems with one generic mechanism. We don't understand the issues sufficiently to make a good, lasting decision. I also think there's no particular pressure to do so. -- Cheers =8-} Chipsy Friede, Völkerverständigung und überhaupt blabla