On 02/07/2015 14:43, Ulrike Fischer wrote: > I had problems with some keys because I hadn't really paid attention > to the order of the declaration. Some tests revealed then that some > key properties (e.g. .code:n) overwrite other (e.g. .groups:n and > .default:n). I don't know if it is a bug but imho at least it should > be mentioned in the documentation. > > \documentclass[parskip]{scrartcl} > > \usepackage{expl3} > \begin{document} > \ExplSyntaxOn > > \keys_define:nn{test} > { > key .code:n = {show~key~(#1)~}, > key .groups:n = {show}, > key .default:n = {XX}, > %different order: > keyb .groups:n = {show}, > keyb .default:n = {XX}, > keyb .code:n = {show~keyb~(#1)}, > } > > Key:~\keys_set:nn{test}{key,keyb}~\\ > Group:~\keys_set_groups:nnn {test} {show} {key=A,keyb=A} > > % a change of the .code:n property > \par > \keys_define:nn{test} > { > key .code:n = {show~key~(#1)}, > } > > Key:~\keys_set:nn{test}{key}~\\ > Group:~\keys_set_groups:nnn {test} {show} {key=B} > \ExplSyntaxOff > > \end{document} Hi Ulrike, The outcome is by-design but you are right that the docs don't currently make it clear. The logic here is that whilst you can add various properties to a key it's not so easy to have a 'remove properties' set up. It therefore seemed most logical that anything that can be used to create a key implementation (.code:n or a specialised derivative such as .tl_set:N) should simply clear any 'stray' properties already set. Unless there is a really good alternative interface I'll simply document this. -- Joseph Wright