On 03/06/2014 00:17, Will Robertson wrote: > Hi Joseph, > > I think the name and the functionality are sensible. Cool :-) > The first case is what I do in fontspec (but there’s lots I do in fontspec that I probably shouldn't). > I suspect that I’d need to play around with some interfaces to figure out how this would change things. > Thinking along these lines: > > >> \cs_new_protected:Npn \foo #1#2 % #1 = keys >> { >> \keys_define:nn { mymod } >> { >> key-a .preset:n = new-value , >> } >> \keys_set:nn { mymod } >> { >> #1 >> } > > > One thing that becomes a bit harder is unsetting the preset; if I then need to run \keys_set:nn again the preset would either need to be grouped or explicitly disabled. > > (E.g., when setting Letters=SmallCaps for the small caps font before moving on to another font shape.) > > So at least in my use case, and only thinking very briefly about it, I’m not sure if this interface would be a advantage for fontspec — but that’s not to say that it’s not a bad idea, nor either that fontspec couldn't be re-jigged to be a bit more sensible in such matters. > > Cheers, > Will I'm seeing offering a 'preset' concept as a convenience/performance boost, but not necessarily trying to cover everything. The scenario you outline for fontspec is probably tricky to cover without some dedicated code, although I guess one might have key-a .unset: or key-a .skip_preset: I think a more common issue is how presetting interacts with filtering or grouping. Not sure at present, but I suspect the most sensible outcome is that filters/groups apply to preset keys such that only 'active' keys (that potentially could be set) are preset. -- Joseph Wright