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