Re: custom.el shadow

Cleaning out my mail queue (sorry for the delay) ... ms> ** New locations for early package hierarchies. Stephen> On second thought, I see no conflict here with the package Stephen> hierarchies. This would show up in a xemacs --no-packages, right? Stephen> The problem is the shadowing of the name "custom.el", combined with Stephen> users who think logically. Stephen> Once it exists, ~/.xemacs is the obvious place for users to keep other Stephen> dot files (.vm, .gnus, .sc, etc), personal libraries split out from Stephen> init.el, and other third-party stuff they've collected. No? And once Stephen> they've put stuff there, they'll probably put it on load-path, yes? You're probably right, even though I'd say that they'd "probably load it explicitly from `user-init-directory'." Stephen> If that is a bad thing as such, then we should document it and check Stephen> for it. If it's only bad because of the shadowing of custom.el, we Stephen> should change the default value of custom-file. I disagree with both options, mainly because I don't want to change the init stuff once again---the first time around was already a nightmare. If we can find a prominent place to document this (probably the FAQ), then I'm all for it, but I don't see enough of a pervasive problem that we can't deal with it by answering questions. Which I think is OK for people who fiddle with the load-path, who tend to be power users anyway. -- Cheers =8-} Mike Friede, Völkerverständigung und überhaupt blabla