2

In the key-value interface of one of my commands, there is a key name style, and I have defined an alternative name for it as follows:

, name-style    .meta:n             = { name~style = #1 }
, name-style    .value_required:n   = true

However, as you can see from the following example, name-style does not behave the same as name style. What is the reason for this and how should I fix it?

\documentclass{article}

\usepackage{hyperref}

\RequirePackage { amsmath, amsthm }

\usepackage{xcolor}
\usepackage[name-in-link]{create-theorem}

\CreateTheorem { theorem } { number-within = subsection, create-numberless-version  }

\SetTheorem { theorem }
  {
    name-style = { % "name style" works
      , heading style = \color{blue}\textsc
      , crefname style = \color{blue}\textsc
      , Crefname style = \color{blue}\textsc
      , numbering style = \color{red}\textbf
    }
  }

\begin{document}

Current language: \languagename


\begin{theorem}\label{thm1}
  In english.
\end{theorem}
\begin{theorem}\label{thm2}
  In english.
\end{theorem}

\begin{theorem*}
  An unnumbered theorem.
\end{theorem*}

\Cref{thm1,thm2}


\end{document}

Here is the desired result:

enter image description here

Below is the complete set-up of keys, for your reference:

\keys_define:nn { create-theorem-setting }
  {
    , name                        .code:n             = { \exp_args:Ne \NameTheorem { \l__crthm_current_env_tl } { #1 } }
    , name                        .value_required:n   = true
    , name~style                  .code:n             = { \exp_args:Ne \NameTheorem { \l__crthm_current_env_tl } { #1 } }
    , name~style                  .value_required:n   = true
    , name-style                  .meta:n             = { name~style = #1 }
    , name-style                  .value_required:n   = true
    , name style                  .meta:n             = { name~style = #1 }
    , name style                  .value_required:n   = true
    , parent~counter              .code:n             = { \crthm_counter_within:en { \l__crthm_current_env_tl } { #1 } }
    , parent~counter              .value_required:n   = true
    , parent-counter              .meta:n             = { parent~counter = #1 }
    , parent-counter              .value_required:n   = true
    , parent counter              .meta:n             = { parent~counter = #1 }
    , parent counter              .value_required:n   = true
    , number~within               .meta:n             = { parent~counter = #1 }
    , number~within               .value_required:n   = true
    , number-within               .meta:n             = { parent~counter = #1 }
    , number-within               .value_required:n   = true
    , number within               .meta:n             = { parent~counter = #1 }
    , number within               .value_required:n   = true
    , shared~counter              .code:n             = { \crthm_counter_alias:en { \l__crthm_current_env_tl } { #1 } }
    , shared~counter              .value_required:n   = true
    , shared-counter              .meta:n             = { shared~counter = #1 }
    , shared-counter              .value_required:n   = true
    , shared counter              .meta:n             = { shared~counter = #1 }
    , shared counter              .value_required:n   = true
    , number~like                 .meta:n             = { shared~counter = #1 }
    , number~like                 .value_required:n   = true
    , number-like                 .meta:n             = { shared~counter = #1 }
    , number-like                 .value_required:n   = true
    , number like                 .meta:n             = { shared~counter = #1 }
    , number like                 .value_required:n   = true
    , unknown                     .code:n             = {}
  }
3
  • 1
    You've forgotten that #1 will need braces around it: , name-style .meta:n = { name~style = {#1} }. Other than that, I would really encourage you not to have key names with spaces in them
    – Joseph Wright
    Commented Mar 10, 2022 at 12:22
  • @JosephWright Thank you for this! May I ask why are the braces needed here, and what is the reason that you don't encourage key names with spaces in them?
    – Jinwen
    Commented Mar 10, 2022 at 12:28
  • 2
    Spaces in key names is a matter of style. As spaces are ignored in expl3 code blocks, one ends up needing either foo~bar or foo bar depending on the context. There is also a tendency for spaces to be used in an inconsistent manner (some pgf(plots) keys suffer from this). Using hyphens avoids this risk.
    – Joseph Wright
    Commented Mar 10, 2022 at 12:46

1 Answer 1

3

The documented behaviour of l3key is similar to other keyval packages: exactly one outer set of braces will be removed from a value if present. As such

foo = {bar} ,

and

foo = bar ,

are equivalent (as l3keys ignores leading and trailing spaces). This means that with a key setting such as

name-style = { % "name style" works
  , heading style = \color{blue}\textsc
  , crefname style = \color{blue}\textsc
  , Crefname style = \color{blue}\textsc
  , numbering style = \color{red}\textbf
    }

will remove the outer braces and pass

, heading style = \color{blue}\textsc
, crefname style = \color{blue}\textsc
, Crefname style = \color{blue}\textsc
, numbering style = \color{red}\textbf

as #1 to name-style. This is then inserted into

name~style = #1

leading to

name~style = 
, heading style = \color{blue}\textsc
, crefname style = \color{blue}\textsc
, Crefname style = \color{blue}\textsc
, numbering style = \color{red}\textbf

In other words, name style receives an empty value, and you set other keys directly.

The general conclusion is that when passing key values from one key to another, you should always use a set of braces to shield against , or = tokens

name-style .meta:n = { name~style = {#1} }

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .