Manuel Pégourié-Gonnard skrev:
> Joseph Wright a écrit :
>> 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.)
>>
> I agree with this suggestion. IMO, xparse should provide general-use
> post-processing functions, for the convenience of the user and as example, and
> let the user define more such functions, with the provided function named
> \ArgFooBar and a recommandation in the doc that the user-defined preprocessing
> functions use a similar naming convention.
I don't think imposing a specific naming convention for processors is
necessarily a good thing; half the time, a suitable function might
already exist, with no intended connection document command argument
parsing.
Sticking with xdoc2l3-style processors, one could imagine ?{<code>} as
a generic "call out to function with :Nn syntax", with the meaning that
xparse will first execute
<code>\some_tl{<argument to process>}
and then take the contents of \some_tl as the processing result. This
way, an xdoc2l3 @{h} or @{ho} argument could be specified to xparse as
@{ ?{\MakeHarmless} }
and
@{ ?{\MakeHarmless} o }
respectively.
>> 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.
>>
> Maybe I confused pre/post in my previous message. I always meant post-grabbing
> and pre-actual-function-call processing :-)
Me too. When I've written about "pre-processing", it has always been
with respect to the document command body, not with respect to when the
document command seizes control over that part of the document text.
>> (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".
>>
> I'm in favour of option 2. It looks more "extensible", if extensions are ever
> needed in the future.
I'm not so sure it is more extensible. The tricky thing about being
\long is that you have to pay attention to it throughout the
implementation, often to the point of making separate definitions for
long and short cases. Having \long-ness as a flag means you can't add
just a short variant of a specifier, you always have to add short AND
long versions.
But maybe new specifiers wasn't the kind of extension you were thinking
about?
>>> 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.
>
> I think I agree. As you pointed out, the capabilities of a purely expandable
> parser would probably be quite different (no post-processing, less precise
> peeking at least), so using a different function for defining it makes sense.
Good! The ability to define expandable macros in LaTeX3 is one thing
about DeclareDocumentCommand that I've worried about, as I suspect
there are prople using \newcommand to define shorthand macros that have
to be expandable. A separate \DeclareExpandableDocumentCommand command
solves this nicely.
> OTOH, as you mentioned in another message, it would be very interesting to
> detect trivial cases like only 'm' arguments and use the trivial (hence purely
> expandable) parser in this case with DeclareDocumentCommand.
Doesn't help much that the parser is fully expandable, if the command
is \protected and therefore doesn't expand in the first place.
I find the claim (given in some previous posting) that e-TeX shouldn't
have gotten \protected right for alignments curious, however; isn't
that just about the only case of protection that _couldn't_ be handled
satisfactorily the LaTeX2e way?
Lars Hellström
|