Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) by h1439878.stratoserver.net (8.14.2/8.14.2/Debian-2build1) with ESMTP id r6DG4HGA032469 for ; Sat, 13 Jul 2013 18:04:18 +0200 Received: from relay2.uni-heidelberg.de ([129.206.210.211]) by mx-ha.gmx.net (mxgmx110) with ESMTP (Nemesis) id 0Ld4UG-1UG8tf0XPE-00iCex for ; Sat, 13 Jul 2013 18:04:11 +0200 Received: from listserv.uni-heidelberg.de (listserv.uni-heidelberg.de [129.206.100.94]) by relay2.uni-heidelberg.de (8.13.8/8.13.8) with ESMTP id r6DG1IDV003173 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 13 Jul 2013 18:01:18 +0200 Received: from listserv.uni-heidelberg.de (listserv.uni-heidelberg.de [127.0.0.1]) by listserv.uni-heidelberg.de (8.13.8/8.13.8) with ESMTP id r6D7FLmh027238; Sat, 13 Jul 2013 18:01:18 +0200 Received: by LISTSERV.UNI-HEIDELBERG.DE (LISTSERV-TCP/IP release 16.0) with spool id 10267803 for LATEX-L@LISTSERV.UNI-HEIDELBERG.DE; Sat, 13 Jul 2013 18:01:18 +0200 Received: from relay2.uni-heidelberg.de (relay2.uni-heidelberg.de [129.206.210.211]) by listserv.uni-heidelberg.de (8.13.8/8.13.8) with ESMTP id r6DG1HUb020201 for ; Sat, 13 Jul 2013 18:01:17 +0200 Received: from mail-oa0-f43.google.com (mail-oa0-f43.google.com [209.85.219.43]) by relay2.uni-heidelberg.de (8.13.8/8.13.8) with ESMTP id r6DG169C003130 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL) for ; Sat, 13 Jul 2013 18:01:09 +0200 Received: by mail-oa0-f43.google.com with SMTP id i7so14227677oag.16 for ; Sat, 13 Jul 2013 09:01:05 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.60.45.229 with SMTP id q5mr38862179oem.79.1373731265753; Sat, 13 Jul 2013 09:01:05 -0700 (PDT) Received: by 10.76.178.69 with HTTP; Sat, 13 Jul 2013 09:01:05 -0700 (PDT) References: <51C94FA0.1080803@morningstar2.co.uk> <51DD0EBD.6080308@morningstar2.co.uk> <51DF2000.30703@morningstar2.co.uk> <51E12031.4060600@morningstar2.co.uk> X-Google-Sender-Auth: eMnbt8vkO-XoN76nW3ODtfDvILQ Content-Type: text/plain; charset=ISO-8859-1 Message-ID: Date: Sat, 13 Jul 2013 12:01:05 -0400 Reply-To: Mailing list for the LaTeX3 project Sender: Mailing list for the LaTeX3 project From: Jura Pintar Subject: Re: l3keys feature request To: LATEX-L@LISTSERV.UNI-HEIDELBERG.DE In-Reply-To: <51E12031.4060600@morningstar2.co.uk> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Envelope-To: X-GMX-Antispam: 0 (Mail was not recognized as spam); Detail=V3; X-GMX-Antivirus: 0 (no virus found) X-UI-Filterresults: notjunk:1;V01:K0:P1XKexTopKM=:5IQN2tmKjD9S8flcSX4beB DJ/p7LqvBOA0B/rIiVmJ0uHkVMJ+Wu3fGdc/cuQWX04osGPKmakbfVLd52qmasylsSgSv1l qpvInAaaqmH2A4b6t0AOmLQN4/LawehSNwWOxYOJdevyLPMTjPbL/wxziERmD0LsYhWp37O /tUJmcxzVlEZDnjbhVoA8+4w2BIuUr0mQNuUH6vUoiEvlUsMVdM1jmRlOKNuqxV1CJqQiMR yFvZAy7FCx43g8Wy0IgDWGHHGAaJ6PDRzhA7AKLYZC1pK9l4e8Id+/DUaQLiU8AKJ20KDFb 94ZUWFGRQV/yvJR/qBxjLAghAwqWNsQQPONBKFbI6Qnh/cwuiQjVKM4CVRec3ZFnpLDE21Y R33eA42zM+WDO4+6VmFg2MMcecqblT+rlZbTcjIaIw1bIcquJAbP6LLeT1/zTkxG0Os4CH6 uFBj4LlGJZsFzejKaNTKaobFc+s3NN5HBpl4HZiZJ0IOPk0mb5yxz5QIa/WwEGB2KqgFoMb 2WbRN94DAjqtWu0VPSoJdV5g6mgyvTMS13K0k80f2rXhwVExnhUBIeIs9IudW29Z74FwzUu 7lyvDT9CkXT5ar6G6JNrBtPb1aWCDqLYPsF0EGsLk+QDHKGAU4LVakg6MC5nksE01oLsz5R dAEIu4YPsjSChGU1hb+sNpIfSj5KyhaVpnHn5DdSZUZ/B62e3s0zljCIr2aMMJChVsD/vO8 oj2lYGXGxYBhhflVvT/NzcglJIiNdpiw/BEuOabDj757O1YtlgUUj8/gb06Pw+KIApagY+F akhR7ZTJlyRRf/V/Y4fX1BdaLPLVDYu0xcqZ7DnZi5CrjAc/S330SqxgoSxaXi4nnEuE5iW I/B/12Io7816MLvM4zKu1ygCUGfcoQWiH7r7GdUxx6nFpmrfSbFJj7GFz4/lXN30buKGqpN eMA9+daHzbbGi8oHg3Z0nXkg+4gkpQU+Yd07n2RIMoQtFcn6cJEbtUrVjzzQeSew7A8T/sZ bLEU4Tzy16lR8rgkys4Kqu1OfwbqFx+dKUe3Pesuy08RUsRLQPTLc5xQUIzblfCl34ecnK2 +tvAAbf+Kt4aXLaAW79IfwsILb+iRprigFf6v7LAGoj3CBlTRX8eUtjmRIimIKCfOUkhIjh ouyPPpa/8sJWhidUgrWjgCG/CDzXH3usHyC8hZQU8TKeOu2tuPEH/npXFxz4qqxMjZhvS3f E+xo88sHNmzhIAMLhQEhSPVUc9GPZN0dqutSdopzlBraWNBEvdZu8T92743z3L8xvn7VQpp TH9ZaESzCkmJpwMFbe2vWSyfR+fa3f40kqJ1wm6c0GYj/9sYpAt9NnTO47/hGKVFzEExBEB bPzgloMAOk5yGfyOx6tdvtuIOvW24LMXA4tH9lzpofDm0gzd+03yFNimOzKG8Y53j4WWTo7 G3H7cz8G4Zeh7cRtrnxbLrvRixgqRyaatgSt7rANRtv+5NswdOnvPrjOWfPUwC2FTrSVLkT HxG2GwAwYXnF9Bh5P0gLdc9O3NOU8AQnj1wWFMR1f6Cz1aGmjmR7AYYCHE82uRBGhhfhjEP S97DarDlGdDYVorR8/3L5eAUVxKMJfukF13xCJkRHxnp3weAs4HmgpTyBmE= X-UI-Loop:V01:nuMcfK+g83w=:H5fo6PSyvGZYb1Q83maVVnPC4Q/VDeOtMb7XB+ZVAmQ= Status: R X-Status: X-Keywords: X-UID: 7243 Hi Joseph, This looks really great! I'm especially fond of the 'opt-in' vs. 'opt-out' split. Thank you for putting in all the effort (and this has been very useful to me regardless of the final product - I always learn a lot reading your code). > I don't see a lot a real use cases for nesting, while I do see > quite a bit of complexity in allowing it! Agreed. > Worth bearing in mind that grouping is intended for the case > where you want to have a 'second axis' for keys. If you always > want to be able to set stuff in an order, then > \keys_set_known:nnN plus subtrees already works. Sure - that's what I've been doing, too, in the packages I'm working on. The filtering mechanism would still simplify this for cases where different subsets of keys need to be set in order in different places, but I'm not thinking of this as the primary function of storing the unused key. It was just the first example to pop to mind. Another use that I can think of off the top of my head is that it allows us to easily give detailed warnings to users when they're attempting to use keys in contexts where they shouldn't be. > The following implements that, but note that you will need the 'burning > edge' expl3 from GitHub/SVN as I've made some adjustments to the l3keys > code to allow for things we certainly will want whatever the final form > of groups/families. Saw that. :) I'm still not entirely sure about the handling of unknown keys. On the one hand, I think there is a substantial conceptual difference between keys that shouldn't be set because they're not in a group on the 'opt-in' list or they're in a group on the 'opt-out' list, and keys that cannot be set because they're undefined. For one, I expect users are likely to pass a disallowed key to a document command because they've not read the the documentation carefully enough (and then such a key can be filtered out), but when they pass an undefined key, they're likelier to have just made a typo. So they should get different notifications in the two cases. On the other hand, I agree that passing an undefined key to \keys_set_groups:nnn should normally be less bad than passing such a key to \keys_set_filtered:nnn. Maybe unknown key errors should be demoted to warnings in this case? Perhaps it would be altogether better to have both a \__keys_store_unused: and a \__keys_store_unknown: with two associated clists, and then distinguish between \keys_set_:nnn and \keys_set_known_:nnn (and possibly have a \keys_set_known_:nnnNN in addition to \keys_set_:nnnN). Finally, there's a small bug in the definition of \keys_set_filter:nnnN. Should be \cs_new_protected:Npn \keys_set_filter:nnnN #1#2#3#4 { \clist_clear:N \l__keys_unused_clist \keys_set_filter:nnn {#1} {#2} {#3} \tl_set:Nx #4 { \exp_not:o { \l__keys_unused_clist } } } And we're missing \cs_new_protected:Npn \keys_set_groups:nnnN #1#2#3#4 { \clist_clear:N \l__keys_unused_clist \keys_set_groups:nnn {#1} {#2} {#3} \tl_set:Nx #4 { \exp_not:o { \l__keys_unused_clist } } } I also expect you wrote this before including \__keys_store_unused: in the GitHub version, so it's not needed again here.