On 03/06/2014 00:50, David Carlisle wrote:
> 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

Presetting is I think quite a specialist case: as you say, with graphics
one would expect

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

to use the 'normal' convention that keys set globally automatically
apply to individual uses unless overwritten: very common approach  in
packages, normally based on applying a group.

I can see how one might set up a 'preset if not already set' approach,
but I'm not sure how it's different from simply starting off with a
default. The point, as I understand it, of allowing presetting is to
cover cases where each 'set' operation should have a know starting point
that isn't influenced by the 'surroundings'.
-- 
Joseph Wright