-
Notifications
You must be signed in to change notification settings - Fork 2
Description
there is no suitable interface on github for proposals, hence I use the issue tracker
in my experience of kvoptions, I have been frustrated by the lack of a \DeclareCodeOption.
If I issue \DeclareStringOption [foo]{bar}, and then later issue \AddToKeyvalOption*{bar}{some code}, it is too late because some code will not have been executed at the time of the [foo], hence whatever some code does, on has to execute it explicitely with parameter #1 being foo.
\DeclareCodeOption [100pt]{bar}{\dimen@=#1\relax} would do the initial assignment \dimen@=100pt\relax. If the package receives the option bar=200pt, then the \dimen@=200pt\relax will get done. If the package receives no option, the default assignment has been done.
Currently I have to do three things: \DeclareStringOption, do the assignment, and do \AddToKeyvalOption to generally set the key handling. Also, \DeclareStringOption defines a macro expanding to foo which I can judge (*) has no utility. In the end I ended up using \define@key directly.
(*) I mean by that: in some contexts, the kvoption user can judge that there is no need for a macro holding the value. In some other contexts naturally it may be useful that a macro keeps the memory of the option value.
edit: I chose hastily "CodeOption". Perhaps, \DeclareProcessOption, \DeclareOptionHandler, \DeclareProcessedOption, \DeclareParameterOption, \DeclareActionOption... but \DeclareCodeOption makes it sound like the option value was supposedly code, which is probably not the good way to think of it (especially as it is supposed to give an interface to <do some default thing>+ \define@key to do the same thing with value of option if need be.