Sender: |
|
Date: |
Wed, 10 Jul 2013 08:16:17 +0100 |
Reply-To: |
|
Message-ID: |
|
Subject: |
|
MIME-Version: |
1.0 |
Content-Transfer-Encoding: |
8bit |
In-Reply-To: |
|
Content-Type: |
text/plain; charset=windows-1252 |
From: |
|
Parts/Attachments: |
|
|
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
|
|
|