Content-Type: multipart/signed; boundary=Apple-Mail-1-111354684; micalg=sha1; protocol="application/pkcs7-signature"
Mime-Version: 1.0 (Apple Message framework v935.3)
References: <4A2F5FE3.3030205@morningstar2.co.uk>
            <qunzxqiuyjyg.dlg@nililand.de> <4A300B9E.4000608@morningstar2.co.uk>
Message-ID:  <8C8871A5-B9AF-4EF4-8AAA-F282C1D206A0@gmail.com>
Date:         Thu, 11 Jun 2009 17:18:46 +0930
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: Will Robertson <wspr81@GMAIL.COM>
Subject: Re: Key-value input
To: LATEX-L@LISTSERV.UNI-HEIDELBERG.DE
In-Reply-To:  <4A300B9E.4000608@morningstar2.co.uk>
Precedence: list
Status: R

--Apple-Mail-1-111354684
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed;
	delsp=yes
Content-Transfer-Encoding: 7bit

Hi all,

Some rambling general comments below.

On 11/06/2009, at 5:08 AM, Joseph Wright wrote:

> The spaces really should not be an issue: it
> is all building things from csname.

I've even toyed with the idea, when dealing with keyval input in  
fontspec, (never happened though) of normalising all keyval input by  
stripping spaces and hyphens, and lowercasing the result. So the  
following would all be equivalent:
   number case=
   NumberCase=
   Number-case=
and so on.

Not actually sure if that would be a good idea (one person commented  
something like "why reward the user for incorrect input?"). Easier for  
the user, however, who must deal with multiple packages in which one  
has CamelCaseKeys, another "keys with spaces", another with  
keysruntogether.

* * *

Regarding keys3 vs template, I'm still firmly on the fence. I think I  
need to implement something reasonably complex from scratch and see  
how both fare. One thing that template seems to do nicely is  
inheritance; what would be the equivalent process in keys3?

To the advantage of keys3, I agree that being able to change the  
default value of a key independently is very desirable. Another  
feature that template doesn't support as easily is the idea of an  
explicit set of named options such as keys3's .create_choices:nn and  
xkeyval's \define@choicekey.

* * *

I'd like to explore the idea of auto-detecting the variable type (by  
stripping off and examining the trailing "_xyz" of the variable) to  
determine which _set function should be used; this could simplify many  
of the common use cases for both packages. Since it would only need to  
be done when first setting up the key, the performance hit should be  
completely reasonable.

After all, what's the point of having some nicely rigid naming schemes  
if we never take advantage of them? :) But even better is that this  
scheme could allow assignments to other types of variables (such as  
clists) without any extra work.

E.g.,

\keys_manage:nn {module/caption/} {
    above-skip/.set:N = \l_caption_above_skip ,
    above-skip/.default:n = 5mm ,
    caption-name/.set:N = \l_caption_name_tl ,
    caption-name/.default:n = {Figure}
}

or

\DeclareTemplate{module}{caption}{4}{
   above-skip = n [5mm] \l_caption_above_skip ,
   caption-name = n [Figure] \l_caption_name_tl
}{...}

* * *

Anyway, what I've said above doesn't really help the discussion much  
but it might spark a couple of new ideas.

Will


--Apple-Mail-1-111354684
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGITCCAtow
ggJDoAMCAQICECN4qE5kBXLk2f/jVDfSZPwwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx
JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ
ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDEyOTA1NDkxNVoXDTEwMDEyOTA1NDkx
NVowQjEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEfMB0GCSqGSIb3DQEJARYQd3Nw
cjgxQGdtYWlsLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL0BeSiAbKuqxeRN
p2qn/m8ZL+xawr/WXyPgEF0FipWgRe9l3sMXcFHokcUu0xOc97R7xkUsGcQ8EyybGHuWey6x7X1Y
xJZXnoAxqcaG+eREytoYGMIKs6BhEEogLVb2ERw3lQNVnOzanSFeGo8suMAN4zzCtqAjJiA1ph7h
1pksTgECYK5EiIZbFsB6zSDa8crNk404z1CfIA6YO8ezvjbDda+D0r8NU2tq9WS9F5IaG+bW71Ya
JegEcSZ+WF6Z+fs2MUMCLLu8n50Er0nuy4dxOmkdMRNfbeaM39dsEwjAAgcQnvPNmlJ215nZWQRH
49YowtSBOYUYq0ZylWRE6x8CAwEAAaMtMCswGwYDVR0RBBQwEoEQd3NwcjgxQGdtYWlsLmNvbTAM
BgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBABaRP8+PDYpKIRGlFgjs1HvMmJnqu4reSqp+
ulv0zJZIjIbX/sLbIsnecl9nycHfhubPdc+hDfpCqNZ2+NGQHwwoyuDl7KOdTY0BDPp3eJLio7ob
EYEr0H8rFwqfx2LWJ0G6nMhNEjLvs7sFKyriSpk++TWJnnsf86xai5m0tlOwMIIDPzCCAqigAwIB
AgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2Fw
ZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UE
CxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNv
bmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUu
Y29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNV
BAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h
bCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7
TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/
cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8YQRA
HmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDagNIYy
aHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYDVR0P
BAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG
9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8
/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQ
Gls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAxAwggMMAgEBMHYwYjELMAkGA1UEBhMCWkExJTAj
BgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJz
b25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAjeKhOZAVy5Nn/41Q30mT8MAkGBSsOAwIaBQCgggFv
MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA5MDYxMTA3NDg0N1ow
IwYJKoZIhvcNAQkEMRYEFLhnewpwvkLpEacPeEwd7KYGnnkaMIGFBgkrBgEEAYI3EAQxeDB2MGIx
CzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYD
VQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQI3ioTmQFcuTZ/+NUN9Jk
/DCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29u
c3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNz
dWluZyBDQQIQI3ioTmQFcuTZ/+NUN9Jk/DANBgkqhkiG9w0BAQEFAASCAQAIWu3JGF9Jl719pm7a
gVp2xVyxT2G9ESKleXCPtAj0ol+mKMcefjv63BMVaYxk+SBSaV4wHShdsjaJR99D2W1D2l7Lwz3n
/kMcOGpKZ7fel4qJtYVianZ0EBaeVwP0oGx2RMvIG4p/qsmZprvTrN6PwZYxQ5rh0r32fd6iVT9y
aV2ZHdXoltENyFgIWqKjg51E6zao+1a1Gp6flGv3bBTxUVuCaAogET4t8U4gBrNre9QfNmUcXemY
xJf+60R6qFAdLjjAkoSDW+VOxBIupm8m4/eKKUF7CWt+cjQCLe8Bxivbk2TvfptSznC/RFvybyup
IKVonLtw1aWtClcmsQQlAAAAAAAA

--Apple-Mail-1-111354684--