Lines: 81
References: <11lm3sqjz6xux$.dlg@nililand.de>
            <5595661F.1070304@morningstar2.co.uk>
            <CA+jHFwSTVzJ4VYb9tF5n2tgX1hU821hG32_JKQLBfWVZ=SnxTQ@mail.gmail.com> <55962878.5030204@morningstar2.co.uk>
            <bbkmg4gzwky6.dlg@nililand.de> <55A4A8D2.6060304@morningstar2.co.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
User-Agent: 40tude_Dialog/2.0.15.41de
Message-ID:  <1bc6qigbj7juc.dlg@nililand.de>
Date:         Tue, 14 Jul 2015 10:13:40 +0200
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: Ulrike Fischer <news3@NILILAND.DE>
Subject: Re: Order of key declarations
To: LATEX-L@LISTSERV.UNI-HEIDELBERG.DE
Precedence: list
Envelope-To: <rainer.schoepf@GMX.NET>
Status: R

Am Tue, 14 Jul 2015 07:14:42 +0100 schrieb Joseph Wright:

> On 03/07/2015 08:58, Ulrike Fischer wrote:
>> - .default:X can imho be reset with .default:n= {}.
>> - .groups:n can imho be reset with  .groups:n = {}.
> 
> As previously noted, I'll alter this behaviour for .groups:n so a blank
> version means 'remove from grouping'. I'll also document that.
> 
> The .default:n is different: an empty default is not the same as no
> default at all (as a default means effectively a value is always given).

In many cases it is. E.g. I could see not difference with the
.code:n or .tl_set:N. And even choice keys works without a default:

\documentclass{article}
\usepackage{expl3}
\begin{document}
\ExplSyntaxOn
\keys_define:nn {test}
{ 
testa .code:n     = {the~argument~is #1!},
testb .tl_set:N   = \l_test_tl,
testc .choice:,
testc /   .code:n={xxx},
}

\keys_set:nn {test} {testa,testb,testc}

\tl_if_empty:NTF\l_test_tl{~empty}{not empty}

\ExplSyntaxOff

\end{document} 

But  .default:n={}  wouldn't work with bool. 


>> -  the action can be reset by setting a new action.
> 
> True, and again I will clarify docs.
> 
>> Missing is ".value_not_required:" and ".value_not_forbidden:". 
> 
> I wonder if best would be to deprecate current .value_required: and
> .value_forbidden: and go to .value_required:n and .value_forbidden:n
> taking boolean values? 

Imho it would be more logical to use booleans. But deprecating
things is naturally always difficult ...

>> Missing is an explicit ".unknown:", which would e.g. allow to remove
>> choices from a key. An accompayning ".known:" which reactivates the
>> key would be interesting too. (I don't know if the code allows
>> this). 
 
> As previously noted, making a key unknown removes the code behind it
> entirely. Unless there is a compelling use case I'm minded to leave this.

If there is an .undefine: action it should be possible to remove a
choice with testkey / choicea .undefine:, so an .unknown: is not
really needed. 

> Based on the fact that as far as possible the key property names follow
> other expl3 things (see .tl_set:N, etc.) I will probably go with
> .undefine:, although .unknown: would also fit nicely with the way keys
> are described.

For me ".unknown:"  is a property, ".undefine:" an action. If code
is destroyed I would use the second. 


Side remark: Did you saw this question on tex.SX:
http://tex.stackexchange.com/questions/254878/mactex-2015-running-much-slower-than-mactex-2014/254946#254946

I wonder what the expl3 code of mhchem is doing there. It looks like
very long recursions ...

-- 
Ulrike Fischer 
http://www.troubleshooting-tex.de/