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