Sender: |
|
Date: |
Sun, 23 Aug 2009 16:28:48 +0100 |
Reply-To: |
|
Subject: |
|
MIME-Version: |
1.0 |
Content-Transfer-Encoding: |
8bit |
In-Reply-To: |
|
Content-Type: |
text/plain; charset=ISO-8859-1 |
From: |
|
Parts/Attachments: |
|
|
Manuel Pégourié-Gonnard wrote:
> I think there is no better way, and the only possible thing to do about it is to
> clearly document the limitations of this approach, and warn that
> \DeclareExpandableDocumentCommand should only be used if absolutely necessary.
>
> (Btw it's probably already done in the doc: I didn't have time to read the
> lastest version, just coming back from holidays, sorting mail first...)
>
> Manuel.
>
Indeed, I put:
% There are \emph{very rare} occasion when it may be useful to create
% fully expandable document commands. To support this, \pkg{xparse}
% can create expandable functions as well as the usual robust
% ones. This imposes a number of restrictions on the nature of the
% arguments accepted by a function, and the code it implements.
% This facility should only be used when \emph{absolutely necessary};
% if you do not understand when this might be, \emph{do not use these
% functions}!
and also
% Parsing arguments expandability imposes a number of restrictions on
% both the type of arguments that can be read and the error checking
% available:
% \begin{itemize}
% \item The last argument of the function must be mandatory
% (type \texttt{l}, \texttt{m} or \texttt{u}).
% \item All arguments are either short or long: it is not possible
% to mix short and long argument types.
% \item The `optional group' argument types \texttt{g} and
% \texttt{G} are not available.
% \item It is not possible to differentiate between, for example
% |\foo[stuff]{argument}| and |\foo{[}]{argument}|. As a
% result, checking for optional arguments is less robust than
% in the standard version.
% \end{itemize}
I hope that basically covers it (anything else important?).
--
Joseph Wright
|
|
|