LATEX-L Archives

Mailing list for the LaTeX3 project

LATEX-L@LISTSERV.UNI-HEIDELBERG.DE

Options: Use Classic View

Use Monospaced Font
Show Text Part by Default
Condense Mail Headers

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

Print Reply
Mime-Version: 1.0 (Apple Message framework v936)
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Date: Fri, 23 Oct 2009 17:04:46 +1030
Reply-To: Mailing list for the LaTeX3 project <[log in to unmask]>
From: Will Robertson <[log in to unmask]>
In-Reply-To: <[log in to unmask]>
Content-Transfer-Encoding: 7bit
Sender: Mailing list for the LaTeX3 project <[log in to unmask]>
Parts/Attachments: text/plain (44 lines)
On 23/10/2009, at 4:34 PM, Joseph Wright wrote:

> Will Robertson wrote:
>> On 23/10/2009, at 6:55 AM, Joseph Wright wrote:
>>> This would allow things like:
>>>
>>> > \ReturnVariable { \MakeHarmless\ReturnVariable }
>>> % Will absorb one more argument, as required
>>>
>>> (using \MakeHarmless from xdoc). That doesn't work at present as  
>>> the return has to be in a toks.
>>>
>>> As Lars points out, that is quite a bit more flexible at the cost  
>>> of a little complexity in the syntax.
>> I'm not sure that I see how this is any more flexible?
>> Oh, simply that your argument processor doesn't have to be hard- 
>> coded to use \l_xparse_arg_toks.
>> But hang on, can't you do the same thing at present by just writing
>>    > { \MakeHarmless\l_xparse_arg_toks }
>> ?
>
> No. \MakeHarmless has the syntax:
>
> \MakeHarmless <macro> <input>
>
> where <macro> is used for the output. So if you try to use a toks  
> here, it will fail to work correctly. You'd need a wrapper function,  
> which is what Lars is suggesting we should avoid.

Ah, and then I guess you use V expansion to get the output from  
\ReturnVariable regardless of whether it's a toks or a macro.

Hmmm. Well.

I suppose it's out of the question to have both options, where  
">{\processor}" is a shorthand for, say, ">> \l_xparse_arg_toks  
{\processor}". Or have ">*{\processor}" that uses \l_xparse_arg_tl  
instead.

Both of these solutions seem to be more like avoiding the issue than  
solving it :) They certainly don't help simplify the situation.

-- Will

ATOM RSS1 RSS2