J.Fine wrote: >> Sorry, I'm a bit lost! Which bit of the thread are we talking about? >> (xparse as-a-concept, post-processing arguments, how to specify >> arguments, ... ) > > All of the above, taken together. > > One starts with parsing key-value arguments in TeX macros, then further features are required, and you start adding features to the LaTeX macros for list processing and the like, and before you know it something has arise that is too complicated for TeX macros. As I see it, the basic idea of xparse is to separate how user functions expect input (stars, optional arguments, mandatory arguments, etc.) from how internal functions work (fixed numbers of mandatory arguments). To do this, the idea is to create \newcommand-on-steroids, so that complex arguments can be processed. For example, \newcommand can't even make two optional arguments or look for a star. So if we take the common example of \section, the code at present mixes input syntax and internal workings. The plan would be to replace it with something like: \DeclareDocumentCommand \section { s o m } { % Code here } where the code always has three arguments #1, #2, #3 to pass down to the underlying structure. The idea is it is then possible to alter input syntax without touching most of the code. There are several questions then to be answered. Some answers agree with your analysis. For example, on verbatim input I feel it has to be done "by hand", and it looks to me like we are generally moving that way. On the other hand, I think the basic idea (as illustrated above) works okay: the code does exactly what is expected (using the original implementation or my xparse-alt experiments). On the post-processing question, I probably tend to the "do by hand" side again: I'm not sure that the need justifies the extra complexity (of code or of input). However, if the consensus is that it is needed, then I'm keen to do the best job possible on it. Hope this makes clear what is going on (at least as I understand it!). -- Joseph Wright