On 16/05/2015 18:54, Manuel Blanco wrote: > Hello, > > I'm looking for two new argument types in xparse (say L and U, but you > can choose the names yourself) to grab sub or superscripts as optional > arguments. I write here since I'm looking for non-hackish solutions, > so probably written in the same way as xparse itself. > > For instance, if we have a command \foo defined with { m o L U } it > should be able to grab \foo{a}[b]_{c}^{d} with `c` and `d` as #3 and > #4. That is, that arguments should check for tokens _ and ^ (like t_ > and t^) and in case they are pressent grab the next argument. > > There's a problem with the naming, since l and u are already taken, L > and U should be followed by the “default” of the optional arguments, > but that would live us without the option to say > \IfValueT{#3}{\sb{\mathrm{#3}}}. I think that with L{<default>} and > U{<default>} is enough (but if you think of a better naming tell!). > > And I think that's all the important. > > --- > > (Now this are just thoughts.) > > In any case, may be not now, but in the future, it would be nice to > have certain control over subscripts (and super..). Right now > subscripts are the most “uncontrolled” optional arguments. But xparse > seems pretty good to add control over them within a macro. > > In an ideal future it would be perfect if xparse could process them > even if they are in different order like ^{a}_b, but for now it's okey > if they are just grabbed in the order they are written (i.e., L{} U{} > => _{a}^{bc}). > > That, with an acceptable interface, would bring us certain power about > limits within the commands we define. Thinking, it may be better > suited as a package alone and not for xparse. > > Thanks! > Manuel Following some discussion at TUG2015, we think this can be done but in a slightly different way. If we think about TeX primitive sub/superscript syntax, the optional tokens are in a non-fixed order. Looked at in a generalised way, that means these are in a sense keyvals but without the 'normal' format. I see you suggested "k" in your follow-up mail: we think that is a sensible ID for a general keyval-like type, so for example \DeclareDocumentCommand\int{k{_^}}{% % #1 = Argument to _ or \NoValue if not seen % #2 = Argument to ^ or \NoValue if not seen } \DeclareDocumentCommand\foo{k{_^!*}}{% % #1 = Argument to _ or \NoValue if not seen % #2 = Argument to ^ or \NoValue if not seen % #3 = Argument to ! or \NoValue if not seen % #4 = Argument to * or \NoValue if not seen } with a K version as well. I will probably work on implementation soon. -- Joseph Wright