Well . . . Hans's ideas sent me scurrying back to The TeXbook (always a good thing) to study the fine print about <parameter text>s. Hans has come up with a useful hierarchical namespace system for macros. All I can say is . . . `cool!'. I was a little concerned about ambiguities in L3PL caused by using _ to separate components, and then allowing _ within components. I think it is good to allow _ within a component (and @ for internals?!) and then use something else (such as /) to separate the components. This will be useful for external indexing programs (e.g. Emacs etags) or even doc.sty. Now bear with me for a few moments of madness. Come to think of it, what follows isn't much weirder^H^H^H^H^H^H^Hmore unusual than some of the details of L3PL. Even if you don't like the particulars, maybe they might trigger a better idea or a totally different application? OK, so now the base's internal macros look like this: \base/ltbibl/@citex and if I write a package called `splat' my internal macros will look like this: \contrib/supported/splat/somethinguseful The result: massive fmt file and control sequence bloat. We need some shortcuts. Here are some possibilities. ============================================================ 1. Use a variant of the Apple solution: author/product codes. E.g. assign a four-(hex-)digit code to a developer. Assume I am allocated a5d4; then my macros begin \a5d4/. . . There might be special codes for e.g. the LaTeX base and packages. ============================================================ 2. Extend doc.sty to do the following: (a) The package writer uses the long names as above when editing the dtx file. We assume that the writer has the help of a good text editor to save on keystrokes! (b) When run through TeX to extract the .cls/.sty/whatever file, the long names of internal macros are rewritten in a canonical, unique-across-all-packages short form, perhaps based on point 1 above. (This must also be the same across TeX implementations.) The package writer might make the renaming explicit or give `hints'; there might be a (more or less) sensible default. (c) Write out a .cut file (for `short cut') which specifies the correspondence between long and short forms. This file could also include macro documentation, error messages, etc. Something like Emacs documentation strings? (Write it out in a format that can be loaded by AUC TeX?) Zillions of possibilities. Maybe .cut is the wrong suffix . . . . People who only use the package don't need to worry about any of this; the `exported' macros have `nice' names. People who want to build on the package can `load' the .cut file in a `special' way which sets up correspondences between long and short names. <- This needs some work to get it right; when you redefine an internal macro you have to redefine both long and short names. Once you are done messing with the internals you can `undo' the correspondences to free up the control sequence space. Error messages relating to internal macros go via the .cut file so that the user sees something `sensible', i.e. using the long names. ============================================================ 3. Similar to point 2 above, but doc.sty writes out two separate .cls/.sty/whatever files, one using the short names and one using the long names. Load whichever you need. You still need the .cut file. ============================================================ 4. As for 3, but write just one file; you specify what you want when you load the file via a [shortnames] or [longnames] option. (Hmm . . . not so good when used as \documentclass[longnames]{blah}; this filters down to later \usepackages unless you override it.) You still need the .cut file. ============================================================ What do you think? Richard.