Mime-Version: |
1.0 (Apple Message framework v935.3) |
Sender: |
|
Subject: |
|
From: |
|
Date: |
Tue, 11 Aug 2009 09:59:54 +0930 |
In-Reply-To: |
|
Content-Type: |
multipart/signed; boundary=Apple-Mail-2-1060454623; micalg=sha1;
protocol="application/pkcs7-signature" |
Reply-To: |
|
Parts/Attachments: |
|
|
Hi,
In my original example writing
\DeclareDocumentCommand \foo { ?{\my_sanitise:n} } {
% do whatever \foo is supposed to do with #1
}
I neglected to include how \my_sanitise:n would actually be written.
And I'm not too sure about that. If it ends up that \my_sanitise:n has
to write to a scratch variable anyway, then I'm not sure we've saved
too much.
I think I'd like to see some more refinements of the idea before
discussing the syntax further.
On 11/08/2009, at 2:23 AM, Manuel Pégourié-Gonnard wrote:
> I think that if you want to support this in xparse then it should be
> accessible
> for all argument types. In my opinion, argument parsing and argument
> preprocessing are orthogonal things, and the syntax should reflect
> this
> orthogonality.
[...]
> If I'm not mistaken, currently the plan is to allow a '+' modifier
> in front of
> every specifier in order to allow for \par in the argument. Maybe it
> is possible
> to add another modifier for preprocessing.
Good thinking. I prefer another modifier over an optional argument.
Does '>\preprocess' work for you? (I like having only a single token
there, but you'd be able to convince me otherwise.)
> Of course it is always hard to find the right balance between
> simplicity and
> features, but in this case my personal preference would be to have
> it included.
I think adding this feature, possibly as "experimental" for now, would
be a good idea.
* * *
In terms of offering expandable optional arguments, I think Joseph's
"wright" that this can't possibly work with more complex argument
types; I might be wrong, however. Perhaps this can be something to
revisit with LuaTeX.
Will
|
|
|