Hans Aberg writes: > Then one may discuss how long the long names should be: Certainly, one > cannot diminish the number of module separators (like "/" in these > discussions), because they tell something about the logical structure. But > it is possible to let the module named "environment" have names starting > "envir/" by simply letting the command \environment/ expand > \environment/<command name> to \envir/<command name>. But then the module > name "envir" cannot be used. Aha, yes, I'm sure this is something else my stomach was thinking about . . . :-) A renaming like this may inadvertently conflict with something else in the system. Perhaps the way around this is to enforce the use of a \newshortcut, which does checking a là \newcommand. > Similarly, the module named "environment" should not be required be in a > file named like that; if one wants to specify a special file or file > position, there should be command doing this. (Such command could be made > to be platform independent between say UNIX, MacOS and MSOS if there is > another command telling which platform it is.) Implementors might take a leaf out of web2c's book - the texfonts.map file. (See the kpathsea documentation.) > So here, they way I see it, the long names (1) are only used really in > order to keep the code straight and avoid code clashes. The user > (preferably also developers) should only need to use short names by various > of simplifying schemes; this is (2) then. But non-local names should expand > to long names. Hmm . . . this is the exact opposite of what I was suggesting. Developers use the long names to make it easier to write; these get translated by docstrip/doc.sty into short names to minimize format size and control sequence usage. Still no word from the Team as to whether this matters for LaTeX3. > When developing the simplifying schemes (2), I do not know how to do it > for the simple reason that TeX is too tricky to program. One can simply not > invent some nice general schemes, then sit down, program it in TeX and hope > it is going to work. Generalities is evidently not Knuth's strong side. I have some ideas about how to implement the suggestions in my earlier e-mail. I don't think it would be too hard; it's primarily a matter of making sure that implementors and package-writers keep to the `rules' (i.e. like always using \newcommand instead of \def). > So (2) must be developed together with (1), so that the two cooperate. Indeed.