Well, after playing a little bit, I think I found a way. The name of the function is k (and K, like d and D), it takes the one token to check, and if it's present, grabs the next (delimited or single token) argument. k <token> K <token> {<default>} Once that is defined, my sub and superscripts are easily defined as shorthands with \prop_put:Nnn \c__xparse_shorthands_prop { a } { k \sb } \prop_put:Nnn \c__xparse_shorthands_prop { b } { k \sp } \prop_put:Nnn \c__xparse_shorthands_prop { A } { K \sb } \prop_put:Nnn \c__xparse_shorthands_prop { B } { K \sp } Here's the full code (may be with errors), in case someone is interested in the future Thanks, Manuel \cs_new_protected:Npn \__xparse_count_type_k:w #1 { \__xparse_single_token_check:n { #1 } \quark_if_recursion_tail_stop_do:Nn #1 { \__xparse_bad_arg_spec:wn } \__xparse_count_mandatory:N } \cs_new_protected:Npn \__xparse_count_type_K:w #1 #2 { \__xparse_single_token_check:n { #1 } \quark_if_recursion_tail_stop_do:nn { #2 } { \__xparse_bad_arg_spec:wn } \__xparse_count_mandatory:N } \cs_new_protected:Npn \__xparse_add_type_k:w #1 { \exp_args:NNo \__xparse_add_type_K:w #1 { \c__xparse_no_value_tl } } \cs_new_protected:Npn \__xparse_add_type_K:w #1 #2 { \__xparse_flush_m_args: \__xparse_add_grabber_optional:N K \tl_put_right:Nn \l__xparse_signature_tl { #1 { #2 } } \__xparse_prepare_signature:N } \cs_new_protected:Npn \__xparse_add_expandable_type_k:w #1 { \exp_args:NNo \__xparse_add_expandable_type_K:w #1 { \c__xparse_no_value_tl } } \cs_new_protected_nopar:Npn \__xparse_add_expandable_type_K:w #1 #2 { \__msg_kernel_error:nnx { xparse } { invalid-expandable-argument-type } { K } \__xparse_add_expandable_type_m:w % May be create this? } \cs_new_protected:Npn \__xparse_grab_K:w #1 #2 #3 \l__xparse_args_tl { \__xparse_grab_K_aux:NnnNn #1 { #2 } { #3 } \cs_set_protected_nopar:Npn { _ignore_spaces } } \cs_new_protected:Npn \__xparse_grab_K_long:w #1 #2 #3 \l__xparse_args_tl { \__xparse_grab_K_aux:NnnNn #1 { #2 } { #3 } \cs_set_protected:Npn { _ignore_spaces } } \cs_new_protected:Npn \__xparse_grab_K_trailing:w #1 #2 #3 \l__xparse_args_tl { \__xparse_grab_K_aux:NnnNn #1 { #2 } { #3 } \cs_set_protected_nopar:Npn { _ignore_spaces } } \cs_new_protected:Npn \__xparse_grab_K_long_trailing:w #1 #2 #3 \l__xparse_args_tl { \__xparse_grab_K_aux:NnnNn #1 { #2 } { #3 } \cs_set_protected:Npn { _ignore_spaces } } \cs_new_protected:Npn \__xparse_grab_K_aux:NnnNn #1 #2 #3 #4 #5 { \exp_after:wN #4 \l__xparse_fn_tl ##1 { \__xparse_add_arg:n { ##1 } #3 \l__xparse_args_tl } \use:c { peek_meaning_remove #5 :NTF } #1 { \l__xparse_fn_tl } { \__xparse_add_arg:n { #2 } #3 \l__xparse_args_tl } } \prop_put:Nnn \c__xparse_shorthands_prop { a } { k \sb } \prop_put:Nnn \c__xparse_shorthands_prop { b } { k \sp } \prop_put:Nnn \c__xparse_shorthands_prop { A } { K \sb } \prop_put:Nnn \c__xparse_shorthands_prop { B } { K \sp } 2015-05-16 19:54 GMT+02:00 Manuel Blanco <[log in to unmask]>: > 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