User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101
            Thunderbird/31.7.0
MIME-Version: 1.0
References: <11lm3sqjz6xux$.dlg@nililand.de>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Message-ID:  <5595661F.1070304@morningstar2.co.uk>
Date:         Thu, 2 Jul 2015 17:26:07 +0100
Reply-To: Mailing list for the LaTeX3 project
              <LATEX-L@LISTSERV.UNI-HEIDELBERG.DE>
Sender: Mailing list for the LaTeX3 project <LATEX-L@LISTSERV.UNI-HEIDELBERG.DE>
From: Joseph Wright <joseph.wright@MORNINGSTAR2.CO.UK>
Subject: Re: Order of key declarations
To: LATEX-L@LISTSERV.UNI-HEIDELBERG.DE
In-Reply-To:  <11lm3sqjz6xux$.dlg@nililand.de>
Precedence: list
Envelope-To: <rainer.schoepf@GMX.NET>
Status: R

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