@cfr Yes, this is a good workaround currently. I just wondered whether it would make also sense to somehow evaluate a string or integer as boolean in other contexts as well ...
@JasperHabicht or use a handy key=value interface that knows the also prefix for key definitions: \ekvdefinekeys{foo}{boolTF key-b = \mypkgIfMyBoolTF, also code key-b = <whatever>} and you set up a boolean key that does additional stuff (but expkv-def's Booleans are not expl3 Booleans) \end{shamelessAdvertisement}
@Skillmon Nice! =) I need expl3 keys in this case ... Is there some naming convention for internal keys, such as __mykey or the like? Would be better probably to hide these using a special key path ...
@JasperHabicht no, I don't know of any naming conventions regarding internal keys. I usually use internal-<key> in expkv, two leading underscores would be fine, too. In both cases you can use a different keyset/path for your internal keys, just use .meta:nn in l3keys or smeta in expkv-def. What sets internal keys apart is only the question of documentation, though.
@JasperHabicht well, not that there are any means for the user to explore the available keys apart from documentation and reading the code. In essence any non-documented key is internal. And just specifying a different path doesn't hinder the user from accessing them regardless (\SetKeys[path]{...}), so the indirection might be cleaner for you, for the user it makes no difference.
@Skillmon Of course, an experienced user is always able to access everything. I typically create some command such as \mypackageset which allows the user to set keys. But these are normally keys in a specific path. So, if I use another path, the user won't be able to access these keys using this macro at least.
I think this is better than having some undocumented key which the user might access by chance. I feel that it is not the best user interface, if such can happen too easily.
@JasperHabicht I'd argue it's roughly as unlikely as a user inputting \SetKeys[jaspers/secret/internal/keys]{width}, namely they have to either be told about those keys, or look them up in the sources.
Don't misunderstand me. If you find your keys to be easier to manage for yourself if you put them in a different path go for it. But don't do it just for the sake of them being internal.
@Skillmon Hm, I don't know ... If I design a macro that users can use, I would like to have it only accept those keys that the user is supposed to use with this macro. Maybe I am too picky here ...
@JasperHabicht that's fine :) Just keep in mind that software should generally be as simple as sufficiently possible. If you have the (self inflicted) requirement that the keys shouldn't be directly accessible via the documented interfaces (even though the keys aren't documented) then go for the separate-path solution.
@Skillmon Software should, while being simple, also be secure and easy to use. At least this is my logic. I think, having a separate path would not really add too much to the complexity. But sure, there are some red lines where I also would say that things are sufficiently secure/easy ...
Think of the `@` or `_`rule ... that you use these letters in macros to prevent a user from arbitrarily using these macros is also something that is probably not always really necessary. Still, I consider it a good way to at least make it harder for the user to go wrong ...
@Skillmon here's the problem the number of arguments is variable (I'm limiting it to 1-4 args)
Was thinking if an input syntax like \Foo{ signature = mm, callback = { ##1, ##2 }, }
Or something better. I was thinking of letting one part of the macro take care of the s O{} part of the arg, and then from the signature and callback define a trailing part of the macro that then gathered up all the mandatory args.
might be that one need a callback-one-arg, callback-two-args, callback-three-args, and callback-four-args (then we don't need the signature). Though it might be a clumky interface.
@daleif for that just make the two keys save the data in tl, then construct a \NewDocumentCommand in the body of your definition \exp_args:NVV \NewDocumentCommand\whatever \l_sig_tl \l_body_tl
@DavidCarlisle and I'm guessing if one want to wrap \l_body_tl, say exp_args:NNVV \NewDocumentCommand\whatever \l_sig_tl { \textbf{ \l_body_tl } }, then one gets into trouble.
Here's what I'm trying (not sure this is a good idea) \NewDocumentCommand\Foo{ s O{} }{ \group_begin: <run precompiled keys, and sysage keys> \__Foo } \NewDocumentCommand\__Foo {mm}{ \_somemacro:n { \l_body_tl} \group_end: } But where \Foo and \__Foo are automatically generated. Might be an XY problem, and one should use a better approach. The reason for \__Foo is so the callback can refer to arg 1-4 and not 3-6 as thats easier for users to understand.
@daleif well you could e-expand it \na \exp_not:N the \textbf so long as teh tokens supplied in the key are assumed safe in that context or add the textbf at key save time using .code and \def\l_body_tl{\textbf{#1}}` or ... or defien a helper macro that defines \def\helper#1#2{\NewDocumentCommand\whatever #1{\textbf{#2}}` then \exp_args:NVV \helper \l_sig_tl \l_body_tl
@egreg (@StefanKottwitz) any chance feynmp-auto could have an option to use r-mpost instead of mpost so it can be used without shell-escape (r-mpost is mpost --restricted and is allowed in teh default shell-escape-commands list)?
