Will Robertson wrote: > Lars Hellström wrote: >> >> For the record, the syntax I'd currently prefer for that is >> >> { >> @{ @{\preprocessorb} @{\preprocessora} O{default} } >> m o m >> } > > For the sake of argument, assume that we're paring down the > functionality of xdoc2l3 to only this and nothing more. (Is that a > reasonable assumption?) While I understand where this one comes from, do > you think at this level that it makes sense to use @ for both for > "bracing" and for "preprocessor defining"? I think I'd be more > comfortable with something like any of the following: > > 1. { m @{ >{\preprocessorb} >{\preprocessora} m } o m } > 2. { m { >{\preprocessorb} >{\preprocessora} m } o m } > 3. { m [ >{\preprocessorb} >{\preprocessora} m ] o m } > 4. { m >{\preprocessorb} >{\preprocessora} m o m } > > If technically possible, I #4 is actually the clearest by virtue of > being the simplest. If the latter syntax is not technically possible, > I'd prefer to optimise the syntax for the case of a single preprocessor, > I think. Writing > { @{ @{\preproc} m } } > is somewhat cumbersome. A simplification to > { >{\preproc} m } > would work well even if example #4 above can't work. I'd also been thinking in similar terms. I'm not very keen on "mix and match" with "m = @ { }" type short-cuts (I like the fact that you can currently count the letters and it is equal to the number of arguments). I'd think Will's #4 is perfectly feasible at an implementation level. The logic is simply: - If token is +, set \long flag - If token is >, collect argument into (say) \l_xparse_processors_seq - Otherwise, fire argument-builder Each argument-builder can then unwind \l_xparse_processors_seq, leaving it empty for the next gathering run. (I'd imagine that s/t would simply ignore any > arguments, and also +, as it is not really applicable.) The "all" the code has to do is recover the processor and get to to act on the value to be processed (either user input or output from previous processor). I don't feel that this plan is too complicated, as most of the time there will either be no post-processing at all, and even if there is post-processing one function is most likely. Are we approaching a consensus on this (if not what everyone considers ideal, at least on something most of us can live with)? -- Joseph Wright