Print

Print


Hello list,

Regarding l3keys, has it been considered the idea of ignoring
whitespace in keys?
I think it would be a good idea, adds flexibility and presents
practically zero problems.

If there's a key defined [do this=true] or [align at=0pt], it's almost
sure that the user or package author hasn't defined [dothis=true] or
[alignat=0pt] to do different things. And if they have defined, I
think the L3 Team can put that in the list of "don't do this" and it
wouldn't be a bad decision.

That implies that spaces are probably not really relevant in key
names, so why not remove them all? That would ease the use of keys,
would let users choose the way to input of keys, and would probably
help those who struggle to remember keys in large packages (e.g., TikZ
/ pgfpplots [xtick] vs. [x tick], [x tick labels] vs. [xtick labels]
vs. [xticklabels], etc.).

Are there any problems or downsides this would cause? May be I'm
missing something, but it sounds all perfect to me.

There would be some small things to take in account, but I think it
would be good.

---

In any case, somewhat related but not much, here's an annoying behaviour.

    \keys_define:nn { foo } { unknown .code:n = { [\l_keys_key_tl] } }
    \keys_set:nn { foo } { \key }

that prints [\key ] with a weird space at the end of \key. I know it's
a “side effect” of \detokenize but still it's a bit annoying. (1)
Spaces are trimmed from the key (i.e., [ foo = bar] => "foo" is the
key, not " foo "), (2) spaces are usually gobbled after control
sequences. So it's weird that [ foo =bar] gives "foo" as the key and
[\foo=bar] gives "\foo " with a trailing space.

What could be done? Does trimming spaces *after* \detokenize would do
any harm? (May be to \tl_set_rescan:?) If not possible to remove, you
could add a note to the manual so it's not a surprise.

Manuel