[moved to xemacs-beta] MS> So OK, the mule files live in lisp/mule, I never realized that. Sorry MS> about that ... MS> I've bumped the recursion depth, but this adds something like 331 MS> stats to the startup time (according to Hrvoje). MS> Now, some files in dumped-lisp.el already have the mule/ prefix MS> explicit like so: MS> (when-feature mule "mule/cyrillic") ; overloaded in leim/quail MS> Any objection against doing the same for the rest of them and MS> reverting the change? Martin> Yes. I object. Martin> It's tradtional that all directories containing .el files are on Martin> the load-path. For example, it's natural to do (interactively) Martin> M-x load-library RET FOO RET Martin> and expect FOO.elc to be loaded. Martin> Although having a nested structure like you propose is Martin> basically a good design (it's like C #include directives), it Martin> breaks compatibility with The Way Things Have Always Been Martin> Done, so don't do it. lisp/term/ can be an exception, since Martin> nobody ever cares about the lisp here. Martin> It's possible you would also break things like find-function, Martin> i.e. any function that might examine load-path. OK, I can see that. I hate the fact, however, that mule/ lives under lisp/ --- it's not a true reflection of the dependencies here. It would be much more natural, IMHO, to have a mule-lisp/ directory alongside lisp/. Martin> That's not to say that file stat optimization isn't important. Martin> I suggest the following design: Martin> Add lisp/ with depth 1 to your list of lisp hierarchies. Martin> (when (featurep 'mule) Martin> Also add lisp/mule as another hierarchy of depth 1. Martin> I haven't looked at the code to see how hard this would be to Martin> implement. Don't worry about that---I'll do it, but I'd like to get it right. -- Cheers =8-} Mike Friede, Völkerverständigung und überhaupt blabla