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:
Tue, 11 Aug 2009 09:59:54 +0930
Content-Type:
multipart/signed
Parts/Attachments:
text/plain (1696 bytes) , smime.p7s (2446 bytes)
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



ATOM RSS1 RSS2