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
Condense Mail Headers

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

Print Reply
Mime-Version:
1.0 (Apple Message framework v935.3)
Content-Type:
text/plain; charset=ISO-8859-1; format=flowed; delsp=yes
Date:
Thu, 3 Sep 2009 10:47:42 +0930
Reply-To:
Mailing list for the LaTeX3 project <[log in to unmask]>
Subject:
From:
Will Robertson <[log in to unmask]>
In-Reply-To:
Content-Transfer-Encoding:
8bit
Sender:
Mailing list for the LaTeX3 project <[log in to unmask]>
Parts/Attachments:
text/plain (38 lines)
On 03/09/2009, at 4:56 AM, Joseph Wright wrote:

> One question occurs to me about xparse "processors". I've provided one
> that splits on a comma, \xparse_process_comma_split:n. I wonder what  
> the
> behaviour of this type of function should be if the input is not of  
> the
> correct form. At the moment, if you apply a processor to an optional
> argument and no value is given, the special \NoValue token is left
> alone.  The normal behaviour for this function is:
>
> \xparse_process_comma_split:n { 1,2 } => {1} {2}
>
> but what should happen with
>
> \xparse_process_comma_split:n { 12 }
>
> A the moment you get "{12} \NoValue" so that exactly two results are
> returned. Should you get perhaps just \NoValue, or something else?

What if I wanted to use more than two 'coordinates'?

   \xparse_process_comma_split:n { 1,2,3 } => {1}{2}{3}

In which case:

   \xparse_process_comma_split:n { 12 } => {12}

In general terms, I think it should be the responsibility of the  
underlying function that is reading the output {12} to pad the braces  
if necessary and call an error if wrong input is given.

On the other hand, if the function were given a more specific name  
then {12}\NoValue would also be an acceptable output.

Just my 2¢
Will

ATOM RSS1 RSS2