11

This question has the following form: 'I know how to do X using Y. I can also do X using Z but not so elegantly as using Y. Can I do X using Z in the same way that I can do X using Y, for a more elegant Z-based solution?'

In this case, Y is TikZ/PGF and Z is expl3 syntax.

Using PGF keys, I can define and/or set a group of keys under a particular path without having to repeatedly specify the path. One way to do this is to use .cd to change the current path until further notice.

<path specification>/.cd, <definition of key 1>, <definition of key 2>, <set key 1>, <set key 2>, 

This makes it possible to provide an easy interface for setting a group of keys.

<group key name>/.code={ \tikzset{% <path specification>/.cd, #1 } }, 

Does the expl3 syntax offer an equivalent of .cd and, if so, what is it?

I can emulate the effect I want by using distinct \keys_define:nn commands for each relevant path, but this seems a somewhat inelegant solution so I'm wondering if I'm missing a more straightforward facility.

MWE showing TikZ case and Expl3 emulation:

\documentclass{article} \usepackage{tikz,xparse} \tikzset{% my keys/.code={ \tikzset{% /top/middle/bottom/.cd, #1 } }, /top/middle/bottom/.cd, key 1/.store in=\keyone, key 2/.store in=\keytwo, } \ExplSyntaxOn \keys_define:nn { top / middle / bottom } { key~1 .tl_set:N = \l_module_keyone_tl, key~2 .tl_set:N = \l_module_keytwo_tl, } \keys_define:nn { top } { my~keys .code:n = { \keys_set:nn { top / middle / bottom } { #1 } } } \NewDocumentCommand \topset { m } { \keys_set:nn { top } { #1 } } \NewDocumentCommand \showkeyone {} { \l_module_keyone_tl } \NewDocumentCommand \showkeytwo {} { \l_module_keytwo_tl } \ExplSyntaxOff \begin{document} \tikzset{% my keys={% key 1=Arrangement, key 2=Ascension, }, }% \topset{% my keys={% key 1=Arrangement, key 2=Ascension, }, }% TikZ/PGF: \keyone{} \keytwo Expl3: \showkeyone{} \showkeytwo \end{document} 

Output:

TikZ/Expl3

1 Answer 1

7

Short answer: no.

The idea of using a keyval approach to setting up keys themselves was (that I know of) first implemented for TeX in pgfkeys. When writing l3keys I looked very hard at this for a model of the most convenient way to create keys and to adjust their behaviour. However, l3keys is not simply a re-implementation of pgfkeys (indeed, there are some outstanding issues in l3keys that may stem from this!). In particular, whilst pgfkeys is object-oriented, that is not true for l3keys. In pgfkeys there is no distinction between 'creating keys' and 'setting keys' and so it is possible to have the .cd concept. On the other hand, in l3keys the two concepts are deliberately separate. This follows the model of keyval (with \define@key and \setkeys).

2
  • Thanks. I never did get on with keyval... ;). I can see the case for separating definition and setting of keys. I don't entirely understand why this makes something like .cd impossible. In fact, something like .cd would make it easier to keep definition and setting distinct, from my point of view, because I wouldn't then need to use \keys_set:nn inside \keys_define:nn at all. Or do you mean that it is impossible to implement something like this? Commented Jan 19, 2016 at 12:42
  • @cfr in theory, it doesn't make something .cd-like impossible to do, but since l3keys doesn't interpret key names other than looking them up during \keys_set:nn, one can't use a mechanism like in pgfkeys. Instead, what one would have to create would be a key that changes the current key path (so alters the effects of the first argument of \keys_set:nn). But a mechanism like this isn't implemented, afaik. Commented May 9, 2021 at 9:43

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.