On 09/07/2013 04:27, Joel C. Salomon wrote: >>> This use of named options feels like it should be reasonably common in >>> user-facing code, but Expl3 doesn’t have an obvious way of managing > this. >>> >>> \keys_define:nn { jcsfonts } >>> { font .choice_code:n = \tl_gset:NV \g_jcsfonts_option_tl >>> \l_keys_choice_tl } >>> >>> \str_case:Vnn \g_jcsfonts_option_tl >>> { { cmodern } {} % Computer Modern is LaTeX default >>> { kpfonts } { \RequirePackage{kpfonts} } >>> } { \msg_error… } >> >> What about >> >> \keys_define:nn { jcsfonts } >> { >> font .choice: , >> font / cmodern .code:n = { } , >> font / kpfonts .code:n = { \RequirePackage{kpfonts} } , >> } >> >> This will trigger a "key-choice-unknown" error upon encountering an >> unknown choice (well, right now the message is not defined... that'll >> be fixed). Maybe we could add a feature to allow arbitrary code for >> unknown choices. > > The code in the various options is more than a single line — about ten > lines per option, actually, and it seems messy to intertwine option > processing with option execution like that. What's wrong with \keys_define:nn { jcsfonts } { font .choice: , font / cmodern .code:n = { } , font / kpfonts .code:n = { \jcsfonts_kpfonts: } , ... font / unknown .code:n = { \jcsfonts_load_unknown:n {#1} } } or similar, i.e. placing the 'payload' in support functions (may be some are can be combined with different args: no idea what the real code is!). -- Joseph Wright