LATEX-L Archives

Mailing list for the LaTeX3 project

LATEX-L@LISTSERV.UNI-HEIDELBERG.DE

Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Manuel Pégourié-Gonnard <[log in to unmask]>
Reply To:
Mailing list for the LaTeX3 project <[log in to unmask]>
Date:
Mon, 10 Aug 2009 21:19:02 +0200
Content-Type:
text/plain
Parts/Attachments:
text/plain (37 lines)
Joseph Wright a écrit :
> As promised yesterday, I'd like to discuss finalising xparse. There are
> two parts to this e-mail: first, a description of xparse for those
> people who are not familiar with it, then in the second part my
> conclusions based on earlier discussion and reading the code.
> 
I'd like to ask about one point, that was maybe discussed earlier: if so, please
excuse me for not reading the archives first.

Some argument specifiers imply peeking at the next token, using
\peek_meaning_remove:NTF (or maybe charcode in the future, but anyway the
unexpandable \peek_token_remove_generic_NTF at some point).

The point is that peeking doesn't work purely by expansion, and it will
sometimes cause problems. A not-so-unfrequently-asked-question is about command
with an optional argument trying to call \multicolumn in a table, ending with
"misplaced \omit" error.

In the 2e world, people have proposed variants of \@ifnextchar "working" purely
by expansion: there is at least xoptarg by Josselin Noirel and more recently
\FE@testopt and \FE@ifstar in Florent Chevret's etextools. Of course those are
not perfect and have their limitations, but those packages probably show there
is an interest for such tests. (I've been using xoptarg in a few personal macros
myself, and already considered implementing similar functionnality in xargs (but
didn't have to come to a decision, since I'm not working on xargs atm)).

So, my question is: do you think it's worth proposing such a feature in xparse?
Of course it would be optional (eg, accessed using a modifier before the
argument specifier invloving peeking ahead) and the limitations of this approach
should be properly documented (unlike xoptarg).

It would be quite a relief for authors wanting to define their personal macros
to be used in tabs, but not wanting (or even able to) handle all the
testing/argument-shuffling involved in writing the argument parser themselves.

Manuel.

ATOM RSS1 RSS2