References: <CAMVYejA5c5g4R0kJHfy+t2KaxSS0H6mW58avLdQN4GcgCdRacA@mail.gmail.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0)
            Gecko/20100101 Thunderbird/38.1.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Message-ID:  <55AF57C2.1070908@morningstar2.co.uk>
Date:         Wed, 22 Jul 2015 09:43:46 +0100
Reply-To: Mailing list for the LaTeX3 project
              <LATEX-L@LISTSERV.UNI-HEIDELBERG.DE>
Sender: Mailing list for the LaTeX3 project <LATEX-L@LISTSERV.UNI-HEIDELBERG.DE>
From: Joseph Wright <joseph.wright@MORNINGSTAR2.CO.UK>
Subject: Re: New arguments for sub and superscripts in xparse
To: LATEX-L@LISTSERV.UNI-HEIDELBERG.DE
In-Reply-To:  <CAMVYejA5c5g4R0kJHfy+t2KaxSS0H6mW58avLdQN4GcgCdRacA@mail.gmail.com>
Precedence: list
Envelope-To: <rainer.schoepf@GMX.NET>
Content-Transfer-Encoding: 8bit
Status: R

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