LATEX-L Archives

Mailing list for the LaTeX3 project

LATEX-L@LISTSERV.UNI-HEIDELBERG.DE

Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Bruno Le Floch <[log in to unmask]>
Reply To:
Mailing list for the LaTeX3 project <[log in to unmask]>
Date:
Mon, 8 Jul 2013 22:26:32 -0400
Content-Type:
text/plain
Parts/Attachments:
text/plain (62 lines)
Hello Joel,

Surely Joseph will have something to say about the topic (he is
currently doing some changes to l3keys), but let me try.

> 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.

> I recently asked “Can I refer to key value in general code?” (
> http://tex.stackexchange.com/q/120258/2966). My initial thought (somewhat
> bizarre, I’ll admit) was to save the option is a quark, set equal to one of
> a group of quarks.

I think that code was missing at least one "_".  Does my answer there help you?

>     \enum_case:Vnn \g_jcsfonts_option_enum
>       { \c_jcsfonts_cmodern_enum {}
>         \c_jcsfonts_kpfonts_enum { \RequirePackage{kpfonts} }
>       } { \msg_error… }

I don't really get the issue with \str_case:Vnn, to be honest, and I
don't see the advantage of an enum type.  Given that it makes the
syntax much more verbose, I am so far not convinced.  Alternatively,
using a property list to hold the code corresponding to each value
could work (and be faster).

> It’s too early for anything to be idiomatic LaTeX3, but what should
> *become* idiomatic?

Well, it's not clear yet if the enum type is that useful.  My second
language after TeX is Python, and the enum type was only added after
something like 20 years, so presumably people lived without it.  An
enum type seems to only be useful if it is significantly more
efficient than a property list ("associative array"/"dictionary") with
empty values.

Regards,
Bruno

ATOM RSS1 RSS2