You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Some document commands expect only a single token as one of their arguments, or expect a single token which should be definable. xparse should provide a means of checking the input for errors of this kind. For instance, \newcommand could be defined as
\DeclareDocumentCommand { \newcommand }
{ s >{\CheckDefinable} m >{\CheckSingle} O{0} O{} m }
{ ... }
The tricky part is to produce an informative error message if the input is incorrect. The error message should preferably contain the name of the DocumentCommand (here \newcommand) which expected its argument to be definable. Perhaps also the position of the argument, but this info may be confusing, for instance the "command" argument of \newcommand is the second one, not the first one as users may think. Perhaps if the argument is mandatory a better number to give is the number as a mandatory argument?
The text was updated successfully, but these errors were encountered:
xparse is primarily aimed at converting user input into code level syntax, and as such it's really up to the code level to check (or otherwise) the input: there are many other invalid input cases that we could chase after. Also, the processor concept is really about manipulating the input to a suitable code-level form, not really checking it, as the set up does not provide a way to 'bail out' of running the code. I also wonder if we could really come up with a good way of firing a generic error which could really be informative: these are really rather tied to the nature of the command being defined.
That said, it might be useful to take an approach similar to that for -NoValue- and have a 'magic' value indicating an error. Something like
\DeclareDocumentCommand { \newcommand }
{ s >{\CheckDefinable} m >{\CheckSingle} O{0} O{} m }
{
\IfInputErrorTF {#2}
{
% Suitable error text here.
}
{ }
}
This does look doable, and also fits with way xparse works. It's also extensible as other possible error checks could be used by individual authors, given suitable code.
I like your proposed \IfInputErrorTF, although perhaps simply \IfErrorTF would be enough. Perhaps we could provide some predefined error-messages in xparse?
Passing thought: required arguments r could return the marker -Error- rather than raise an error directly?
I thought about \IfErrorTF, but it seemed too generic (there are all sorts of errors: do we want to take this name?). No issue with providing 'pre-cooked' error messages, I think.
I'd say the point about r arguments is that them being missing is a parse error, whereas checking if the input is whatever is not. So the two things are different.
Some document commands expect only a single token as one of their arguments, or expect a single token which should be definable.
xparse
should provide a means of checking the input for errors of this kind. For instance,\newcommand
could be defined asThe tricky part is to produce an informative error message if the input is incorrect. The error message should preferably contain the name of the
DocumentCommand
(here\newcommand
) which expected its argument to be definable. Perhaps also the position of the argument, but this info may be confusing, for instance the "command" argument of\newcommand
is the second one, not the first one as users may think. Perhaps if the argument is mandatory a better number to give is the number as a mandatory argument?The text was updated successfully, but these errors were encountered: