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:
Will Robertson <[log in to unmask]>
Reply To:
Mailing list for the LaTeX3 project <[log in to unmask]>
Date:
Mon, 17 Aug 2009 15:23:46 +0930
Content-Type:
multipart/signed
Parts/Attachments:
text/plain (2128 bytes) , smime.p7s (2446 bytes)
On 17/08/2009, at 5:57 AM, Joseph Wright wrote:

>> If you consult the LaTeX3 SVN, you'll see that I've now committed a  
>> lot
>> of what has been discussed here to the real xparse module, removing
>> xparse-alt and doing a little tidying of other xpackages to fit the
>> updated model.
>
> Further to this, an implementation for  
> \DeclareExpandableDocumentCommand
> is now included in xparse in the SVN. In the end, it turned out that
> with a "daisy-chain" implementation multiple optional arguments are
> still okay in fully expandable commands.

Hi Joseph,

Thanks for the great efforts here!
I did a once-over on the documentation (and made a couple of minor  
adjustments) and everything seems logical to me.

To summarise the changes from the old xparse:

-  >{P} replaced by +
-  >{W} dropped, since it is applied automatically when necessary  
(final optional argument(s))
-  c dropped, replaced by 'd()'
-  g and G{} added: optional braced argument
-  d** and D**{} added: pair-delimited argument
-  u* and U*{} added: post-delimited argument
-  >{\processor} added: "transforming" input before it's sent through  
to the main macro code
-  Expandable document commands

I think that's it.

Nice to see the expandable document command definitions in there; I  
suppose time will tell whether they turn out to be useful or not...

The only thing that sort of seems weird to me is that d** uses single  
tokens only as delimiters whereas u* allows multiple tokens. Is there  
a major technical reason that the d argument couldn't accept something  
like d{<<}{>>} for \foo<<1>> ? Actually, I don't care at all to  
support this sort of usage, but it just seems odd to have single  
tokens for one and multiple tokens for the other. Only a comment; I  
don't think anything needs to be done about it, at least at this stage.

Lars, do you have any comments about whether the new xparse is  
something you'd like to use in your own work? Your code, of course,  
was the big motivation for the "argument processor" idea and I'd hope  
that while we didn't manage to fit everything from xdoc2l3 into xparse  
there's still enough that you'd like to use.

Best regards,
Will

ATOM RSS1 RSS2