>>>> "MS" == Michael Sperber
<sperber(a)informatik.uni-tuebingen.de> writes:
>>>>> "Martin" == Martin Buchholz <martin(a)xemacs.org>
writes:
>>>> "MS" == Michael Sperber
<sperber(a)informatik.uni-tuebingen.de> writes:
>>>> "Martin" == Martin Buchholz
<martin(a)xemacs.org> writes:
>>>> "SJT" == Stephen J Turnbull <turnbull(a)sk.tsukuba.ac.jp>
writes:
>>>> "mb" == Martin Buchholz
<martin(a)xemacs.org> writes:
Martin> I'm not sure I understand what the technical problem is right now. I
Martin> assume we're still trying to solve the excessive stats problem.
MS> Yup.
Martin> What was wrong with my technical suggestion of
Martin> - adding core lisp/ as a hierarchy of depth 0.
Martin> - if mule, adding lisp/mule as another hierarchy of depth 0.
Martin> - adding package hierarchies using a different depth.
MS> Because then, the Lisp code treats the two directories as being
MS> side-by-side whereas the physical relationship is "subdirectory of."
This is a far smaller sin than renaming a directory, and is an
implementation detail a user will never notice.
MS> Your stated wish was not to treat mule/ specially, but your suggestion
MS> does just that.
No, other features could be treated the same way. For example, there
could be a "lisp/widgets" subdirectory. Maybe you mistook my meaning
of "specially". There are many places where we have mule-specific
code. That's OK. But we should be moving in the direction of
minimizing those.