LATEX-L Archives

Mailing list for the LaTeX3 project


Options: Use Classic View

Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

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

Print Reply
Will Robertson <[log in to unmask]>
Sat, 8 Jan 2011 18:49:15 +1030
text/plain (46 lines)
Hi Bruno,

Thanks for writing; it's nice to hear from you.

First question: why the name \cprotect? I.e., what does the "c" stand for?

On 08/01/2011, at 5:55 PM, Bruno Le Floch wrote:

> It might be possible to do error checking: each `\cprotect` should check 
> somehow that it is "at the top" (i.e., it is the first one to look at its 
> argument), or that it is within a `\cprotect`ed command. 
>   Any idea how to do that?

Would it work to make \cprotect an \outer macro, then when it performs its \scantokens on its arguments it can redefine itself to be non-outer in this case? For the more generic case when you need to have


I don't imagine there's a way to ensure the \cprotect is present at every nesting level. (Although I suppose it would be possible to have a messy token-by-token scanning routine (a la ted.sty) in which you insert \let\cprotect\cprotecterror after every open brace and \let\cprotect\cprotectnormal after every close brace in a token list, all of which to be reverted iff \cprotect is in charge of the inner brace scanning.)

> For the syntax, the naive thing is to simply get `\cprotect` to  grab all 
> the arguments verbatim, and reread them when needed, but for 
> performance reasons, it could be better to say explicitly for each 
> argument whether it needs `\cprotect`ion. Any suggestions for the 
> syntax in this case?

I'm not really sure if this is needed. \scantokens shouldn't add much performance penalty, but you'll still need some syntax to indicate how many arguments are being included in the \cprotect. E.g., if you wrote


How does \cprotect know what to read in?

> PS: Also, a small crazy idea (I see no practical application for that):
> In LaTeX3, we can generate variants of macros with different types 
> of arguments (using \cs_generate_variant:Nn). Could/should the 
> same thing be done at the layer above? In other words, should it be 
> possible to take a DocumentCommand, and change the delimiters, or 
> change an argument from being optional to being mandatory, or from 
> being mandatory to being  optional with default, ...?

I can't see this being very useful at all :)

-- Will