Received: from mail.proteosys.com ([213.139.130.197]) by nummer-3.proteosys with Microsoft SMTPSVC(6.0.3790.3959); Tue, 11 Aug 2009 08:24:48 +0200 Received: by mail.proteosys.com (8.14.3/8.14.3) with ESMTP id n7B6OoUu001702 for ; Tue, 11 Aug 2009 08:24:50 +0200 Received: from listserv.uni-heidelberg.de (listserv.uni-heidelberg.de [129.206.100.94]) by relay.uni-heidelberg.de (8.14.1/8.14.1) with ESMTP id n7B6JqG9013140 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 11 Aug 2009 08:19:52 +0200 Received: from listserv.uni-heidelberg.de (localhost.localdomain [127.0.0.1]) by listserv.uni-heidelberg.de (8.13.1/8.13.1) with ESMTP id n7AM3P3U010332; Tue, 11 Aug 2009 08:19:42 +0200 Received: by LISTSERV.UNI-HEIDELBERG.DE (LISTSERV-TCP/IP release 15.5) with spool id 286392 for LATEX-L@LISTSERV.UNI-HEIDELBERG.DE; Tue, 11 Aug 2009 08:19:42 +0200 Received: from relay.uni-heidelberg.de (relay.uni-heidelberg.de [129.206.100.212]) by listserv.uni-heidelberg.de (8.13.1/8.13.1) with ESMTP id n7B6JgY0018293 for ; Tue, 11 Aug 2009 08:19:42 +0200 Received: from lon1-post-3.mail.demon.net (lon1-post-3.mail.demon.net [195.173.77.150]) by relay.uni-heidelberg.de (8.14.1/8.14.1) with ESMTP id n7B6JQXE012788 for ; Tue, 11 Aug 2009 08:19:30 +0200 Received: from cremornelane.demon.co.uk ([80.177.25.195] helo=[192.168.0.2]) by lon1-post-3.mail.demon.net with esmtp (Exim 4.69) id 1Makhi-0006EL-dt for LATEX-L@LISTSERV.UNI-HEIDELBERG.DE; Tue, 11 Aug 2009 06:19:26 +0000 User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 References: <4A7921CF.5020803@morningstar2.co.uk> <4A7A1505.4040604@residenset.net> <4A7AD930.2090106@residenset.net> <8516B615-51AA-4D90-BB7D-A9E122AA0335@gmail.com> <4A804317.6050909@morningstar2.co.uk> <4A80508F.3030904@elzevir.fr> <0C83E480-14E3-4CD8-924E-3B9EA602E004@gmail.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Message-ID: <4A810D6E.5050207@morningstar2.co.uk> Date: Tue, 11 Aug 2009 07:19:26 +0100 Reply-To: Mailing list for the LaTeX3 project Sender: Mailing list for the LaTeX3 project From: Joseph Wright Subject: Re: xparse To: LATEX-L@LISTSERV.UNI-HEIDELBERG.DE In-Reply-To: <0C83E480-14E3-4CD8-924E-3B9EA602E004@gmail.com> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-ProteoSys-SPAM-Score: -6.599 () BAYES_00,RCVD_IN_DNSWL_MED X-Scanned-By: MIMEDefang 2.65 on 213.139.130.197 Return-Path: owner-latex-l@LISTSERV.UNI-HEIDELBERG.DE X-OriginalArrivalTime: 11 Aug 2009 06:24:49.0034 (UTC) FILETIME=[6D7EBEA0:01CA1A4C] Status: R X-Status: X-Keywords: X-UID: 5872 Will Robertson wrote: > 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. [snip] > 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.) I'd wondered about something similar. Looking at xdoc2l3, I think there are a couple of obvious post-processors. One is \detokenize given a "design" name (\Detokenize or \MakeString?), and the other is \MakeHarmless. Perhaps also a de-babel function to deal with active characters: \PunctuationOther? (Perhaps all of the functions should make it clear they are argument post-processors? \ArgDetokenize, \ArgMakeHarmless, etc.) In any case, I'd imagine any post-processor being a function of one argument. Internally, they'd do something with a temporary variable, then put the value of the variable back into the input of the underlying function defined by in \DeclareDocumentCommand. I'd stick to post-processing if given the option. Pre-processing can lead to things which only work if the defined function is not nested (back with % again), and I'd prefer not to imply that can work. e-TeX makes post-processing catcodes possible, so saying "first the argument is grabbed, then it is modified" seems okay. >> 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. Yes, provided we agree the other syntax in a more "decided" way that is fine. I'd also thought of ">" as the most obvious way to work this. (Insisting it goes before the specifier makes the code a lot easier to write, but if it is a problem we could put it after.) This still leaves how to handle long arguments. I've suggested two models: (1) Upper/lower-case for \long: \DeclareDocumentCommand \foo { o >\MakeHarmless M } \DeclareDocumentCommand \foo { o{default} >\MakeHarmless M } \DeclareDocumentCommand \foo { O >\MakeHarmless M } \DeclareDocumentCommand \foo { O{default} >\MakeHarmless M } (2) + for \long, upper-case for defaults on optional arguments: \DeclareDocumentCommand \foo { o >\MakeHarmless +m } \DeclareDocumentCommand \foo { O{default} >\MakeHarmless +m } \DeclareDocumentCommand \foo { +o >\MakeHarmless +m } \DeclareDocumentCommand \foo { +O{default} >\MakeHarmless +m } Both seem to look okay with the post-processing idea added in, I think. Based on Lars' comments about having a very clear syntax, can we agree on option (2)? If so, I can implement some of this and then see how it looks "in practice". > 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. I'm very reluctant to introduce something where we end up with a complex warning about what it is for. You can imagine using something like "e = expandable test for optional argument", but explaining what it is for and how to use it then becomes very complicated. If we really do want something like this, I'd think a separate function (\DeclareExpandableDocumentCommand) might be better. -- Joseph Wright