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 18:25:03 +0930
Content-Type:
multipart/signed
Parts/Attachments:
text/plain (2619 bytes) , smime.p7s (2446 bytes)
Hi Joseph,

Short reply. (You said it all already.)

On 17/08/2009, at 4:53 PM, Joseph Wright wrote:

> Will Robertson wrote:
>> 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))
>
> Actually, for the moment I've simply not used any space skipping at  
> all.
>
> Of course, TeX skips spaces after the command name itself, but for
> something like:
>
> \foo{arg1}[arg2]{arg3}
>
> it seemed easier to explain if there is no space skipping at a LaTeX
> level. If other people disagree it is easy to change.

Ah, right. Well, it's hard to explain either way, I think; e.g.,

\foo{a} {b} {c} % works
\bar{a} [b] {c} % does not

Personally, I liked xparse-alt's original method, but I'm happy to  
leave it like this until complaints start coming in :)  (Which I'm not  
sure will happen.)

>> -  c dropped, replaced by 'd()'
>
> I'm imagining that LaTeX3 at the document level might well not need  
> this
> input type too much.

Yup.

>> -  g and G{} added: optional braced argument
>> -  d** and D**{} added: pair-delimited argument
>> -  u* and U*{} added: post-delimited argument
>
> Just u{}: mandatory argument, no default but takes multiple tokens.

Thanks; silly slip of mine.

[Regarding single token delimited arguments:]

> To allow multiple opening tokens, there has to be one check (and
> removal) for each token. That looks rather awkward to write, as you  
> have
> to be able to put back all of the removed opening tokens if not all  
> are
> actually present.

Okay, I have to admit I didn't think about the implementation when I  
thought about it earlier today. (Recovering from a bug, so my head's a  
bit fuzzy. If that's an excuse.)

> More generally, I'd hope that more complex options can be handled in
> better ways than opaque argument syntax. Something like:
>
> \foo[opt1][[opt2]]{arg} % Two opt args [...] and [[...]]
>
> is probably better handled as:
>
> \foo[opt1=text1,opt2=text2]{arg}
>
> in any case.

Most certainly!

> I'd hope we cover enough for almost all non-verbatim circumstances.  
> For
> example, taking Will's question of delimiters, you can make a  
> mandatory
> delimited argument with multiple tokens:
>
> \DeclareDocumentCommand \foo { u{<open>} u{<close>} {
>  \tl_if_empty:nTF {#1} {
>    % Do stuff
>  }{
>    % Probably should not happen!
>  }
> }

Heh; nice. Yes, I think xparse is doing basically everything one could  
ever hope for, at this stage.

Will



ATOM RSS1 RSS2