Joseph Wright wrote: > My feeling is that \DeclareExpandableDocumentCommand, if implemented, > would be explicitly marked up: > > "In general, document commands should be created using > \DeclareDocumentCommand. \DeclareExpandableDocumentCommand is intended > to be used only in *exceptional* circumstances where a fully-expandable > function is *essential*. It has very restricted processing > possibilities, when compared to the standard version." > > I'd then expect us to basically support s, o, O and m type arguments, > with any one \long forcing all to be long (probably by insisting that > any + has to come before the first arg. spec.). I need to look at how s > and o grabbing is implemented in such cases, so the exact restrictions > are "yet to be determined". I would imagine that there would be no post > processing in this case. (Of course, if there are good examples of where > this needs thinking about, it can be looked at again.) I've taken a quick look at things. I think that, when done by hand you can in principal support rather complex things (for example " s o m m o s m m"), but that this looks horrible if done with an automated system. Further, I don't want to encourage people to use this function unless *necessary*, and so far the number of real cases is *very* small. How would the following sound: - All arguments either short or long (I think this is the only way in any case), with "+" then required in front of each letter if any one is to be long so that the input syntax is clear. So "+m m" or "o +m" raise an error, whereas "+m +o" is allowed. - Support only a subset of the possibilities. With "m ... m" representing "one or more m arguments": = m ... m = t<token> m ... m = D<token1><token2><default> m ... m = t<token> D<token1><token2><default> m ... m only (with short-cuts s, o and O allowed in the same pattern). Perhaps not even the last one? -- Joseph Wright