MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Message-ID:  <CAMVYejA5c5g4R0kJHfy+t2KaxSS0H6mW58avLdQN4GcgCdRacA@mail.gmail.com>
Date:         Sat, 16 May 2015 19:54:04 +0200
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: Manuel Blanco <manuelbl@UCM.ES>
Subject: New arguments for sub and superscripts in xparse
To: LATEX-L@LISTSERV.UNI-HEIDELBERG.DE
Precedence: list
Envelope-To: <rainer.schoepf@GMX.NET>
Content-Transfer-Encoding: 8bit
Status: R

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