User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101
            Thunderbird/24.5.0
MIME-Version: 1.0
References: <538C959C.3060904@morningstar2.co.uk>
            <538CA727.1000203@morningstar2.co.uk>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
Received-SPF: None (: nag.co.uk does not designate permitted sender hosts)
Message-ID:  <538D0DD2.2090106@nag.co.uk>
Date:         Tue, 3 Jun 2014 00:50:42 +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: David Carlisle <davidc@NAG.CO.UK>
Subject: Re: 'Preseting' keys
To: LATEX-L@LISTSERV.UNI-HEIDELBERG.DE
In-Reply-To:  <538CA727.1000203@morningstar2.co.uk>
Precedence: list
Envelope-To: <rainer.schoepf@GMX.NET>
Status: R

On 02/06/2014 17:32, Joseph Wright wrote:
> On 02/06/2014 16:17, Joseph Wright wrote:
>> Hello all,
>>
>> A reasonably common use case for keyval method is is the situation where
>> one or more keys are set to a value implicitly. This is often managed in
>> LaTeX using grouping.
>>
>>    % Set up keys
>>    \keys_define:nn { mymod }
>>      {
>>        key-a .tl_set:N = \l_mya_tl ,
>>       ...
>>      }
>>    \keys_set:nn { mymod }
>>      {
>>        key-a = value % Applies unless set otherwise
>>      }
>>    ...
>>    \group_begin:
>>      \keys_set:nn { mymod }
>>        {
>>          key-a = new-value
>>        }
>>    \group-end:
>>    % key-a will be "value" again
>>    \group_begin:
>>      \keys_set:nn { mymod }
>>        {
>>          % No key-a set => "value"
>>        }
>>
>> However, there are cases where you'd like to 'preset' the key every
>> time. Currently, that would require
>>
>>      \cs_new_protected:Npn \foo #1#2 % #1 = keys
>>        {
>>          \keys_set:nn { mymod }
>>            {
>>              key-a = new-value ,
>>              #1
>>            }
>>
>> but that is not that efficient and also not that clear.
>>
>> An alternative approach is to provide a method to 'preset' keys from
>> within the key system, something like
>>
>>    \keys_define:nn { mymod }
>>      {
>>        key-a .tl_set:N = \l_mya_tl ,
>>        key-a .preset:n = value
>>       ...
>>      }
>>
>> where the presetting can avoid having to parse the keys each time it's
>> run (cf. what happens in xtemplate).
>>
>> The team have some use cases where this makes sense, so I will be
>> looking to add it as an experimental idea. Before I do, thought, I'd
>> like to know if the name, etc., makes sense. It's distinct from
>> ".default:n" (used if a key name is given with no property) and
>> ".initial:n" (a 'set up' shortcut).
>>
>> I note that xkeyval offers the idea of preset keys, but in a slightly
>> more complex fashion as it allows 'tail' keys and does some tests for
>> the presence of keys before doing presetting. I don't see a similar
>> concept in the pgfkeys manual: I have a feeling there just the 'manual'
>> approach is used.
>>
>> Thoughts?
> Particular questions here as well as the name are whether 'presetting'
> depends on what is in the key list (should keys be preset if they are
> found in the key list?) and what, if anything, should be done
> differently in the key filtering cases.


This reminds me of

http://tex.stackexchange.com/questions/164116/which-arguments-of-includegraphics-cannot-be-set-beforehand/164132#164132

graphics essentially pre-sets scale=1 (it shouldn't, but it does)

the unexpected user experience as a result of that is that you can go

\includegraphics[scale=2]{...}

but (unlike almost all other keys) you can't go

\setkeys{Gin}{scale=2}
\includegraphics[]{...}

as the key gets set to 2 then "preset" back to 1 before any keys in the 
actual graphics call are handled.

I can't change graphics now, but I suspect that either of the following
two alternatives would have been better


1) initialise the key _at the point of definition_
so scale always had a value (defaulting to 1).


2) preset the key at the point of use, but only if it is
currently unset (ie some internal macro is either undefined or
has some \NoValue value, however it's implemented).


This seems to be a general feature not something specific to graphics/scale
so I wonder if it would be possible to accommodate these choices in a 
declarative
l3keys interface


David