Received: from mx0.gmx.net (mx0.gmx.net [213.165.64.100]) by h1439878.stratoserver.net (8.14.2/8.14.2/Debian-2build1) with SMTP id p7NGiVbI005766 for ; Tue, 23 Aug 2011 18:44:32 +0200 Received: (qmail 9866 invoked by alias); 23 Aug 2011 16:44:22 -0000 Delivered-To: GMX delivery to rainer.schoepf@gmx.net Received: (qmail invoked by alias); 23 Aug 2011 16:44:21 -0000 Received: from relay.uni-heidelberg.de (EHLO relay.uni-heidelberg.de) [129.206.100.212] by mx0.gmx.net (mx082) with SMTP; 23 Aug 2011 18:44:21 +0200 Received: from listserv.uni-heidelberg.de (listserv.uni-heidelberg.de [129.206.100.94]) by relay.uni-heidelberg.de (8.14.1/8.14.1) with ESMTP id p7NGg63Q002336 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 23 Aug 2011 18:42:06 +0200 Received: from listserv.uni-heidelberg.de (localhost.localdomain [127.0.0.1]) by listserv.uni-heidelberg.de (8.13.1/8.13.1) with ESMTP id p7NGe5q0001953; Tue, 23 Aug 2011 18:42:05 +0200 Received: by LISTSERV.UNI-HEIDELBERG.DE (LISTSERV-TCP/IP release 16.0) with spool id 1650493 for LATEX-L@LISTSERV.UNI-HEIDELBERG.DE; Tue, 23 Aug 2011 18:42:05 +0200 Received: from relay2.uni-heidelberg.de (relay2.uni-heidelberg.de [129.206.210.211]) by listserv.uni-heidelberg.de (8.13.1/8.13.1) with ESMTP id p7NGg5Ba007848 for ; Tue, 23 Aug 2011 18:42:05 +0200 Received: from ueamailgate02.uea.ac.uk (ueamailgate02.uea.ac.uk [139.222.131.185]) by relay2.uni-heidelberg.de (8.13.8/8.13.8) with ESMTP id p7NGfkif001137 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 23 Aug 2011 18:41:50 +0200 Received: from ueams01.uea.ac.uk (ueams01.uea.ac.uk [139.222.131.78]) by ueamailgate02.uea.ac.uk (8.13.8/8.13.8) with ESMTP id p7NGcuLo011074 for ; Tue, 23 Aug 2011 17:38:56 +0100 Received: from [139.222.115.140] by ueams01.uea.ac.uk with esmtp (Exim 4.69) (envelope-from ) id 1Qvtz4-0002XI-Vy for LATEX-L@LISTSERV.UNI-HEIDELBERG.DE; Tue, 23 Aug 2011 17:37:51 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 References: <4E4FF538.7070601@morningstar2.co.uk> <9788A2B7-3E8F-4D2C-A52E-10999BCB59FA@gmail.com> <4E516DF2.4040002@morningstar2.co.uk> <104nbkj0nr84x.dlg@nililand.de> <4E523217.2080408@morningstar2.co.uk> <4E52AA87.6090608@morningstar2.co.uk> <1i25hv8yiyx81$.dlg@nililand.de> <4E537C7A.5040605@morningstar2.co.uk> <1konvzgb7ssyz.dlg@nililand.de> X-Enigmail-Version: 1.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Bayes-Prob: 0.0001 (Score 0, tokens from: @@RPTN, outgoing) X-CanIt-Geo: ip=139.222.131.78; country=GB; region=I9; city=Norwich; latitude=52.6333; longitude=1.3000; http://maps.google.com/maps?q=52.6333,1.3000&z=6 X-CanItPRO-Stream: UEA:outgoing (inherits from UEA:default,base:default) X-Canit-Stats-ID: 06FnQCUrd - 8a4a083065dd - 20110823 X-Scanned-By: CanIt (www . roaringpenguin . com) on 139.222.131.185 Message-ID: <4E53D7B6.80109@morningstar2.co.uk> Date: Tue, 23 Aug 2011 17:39:18 +0100 Reply-To: Mailing list for the LaTeX3 project Sender: Mailing list for the LaTeX3 project From: Joseph Wright Subject: Re: couple of l3keys notes To: LATEX-L@listserv.uni-heidelberg.de In-Reply-To: <1konvzgb7ssyz.dlg@nililand.de> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-GMX-Antispam: 0 (eXpurgate); Detail=5D7Q89H36p70EVnmPwpfx/vijE2cyyBv6GDJNO9iW3l1pFBYhDB2JOa2WZJ6GeMxXJ7dM F/7uUfEiB3mj75OZCfFSpF+b8Vx9wv18LZBoQ3kcpgqlqQhfY8dVD8kRDZeheFvNjZMYxaImD68K IkQu5zPiaZVjx+6aZIDhuryAH0vbNfOGEspNa8IYtkEEZa5jAuX5o3THC0=V1; X-Resent-By: Forwarder X-Resent-For: rainer.schoepf@gmx.net X-Resent-To: rainer@rainer-schoepf.de Status: R X-Status: X-Keywords: X-UID: 6827 On 23/08/2011 12:03, Ulrike Fischer wrote: >> Well no, as the special 'unknown' key allows behaviour for a key which >> is not defined to be set up. > > Does keys_set_known makes a difference between modules with and > without such an unknown key? The current approach is that \keys_set_known:nnN only sets explicitly-defined keys. So it does not matter if a set of keys have an 'unknown' value or not. (I'm not quite clear why you'd want to do \keys_set_known:nnN with an 'unknown' value set if this meant that there was no difference to just using \keys_set:nn.) > I'm currently changing chessfss to keyval-syntax. I have to set > properties for board fonts, figurines fonts and other symbols. So I > have a structure like this: > > all chess fonts > family > width > series > size > > fig font > encoding > family > width > series > size > > board font > encoding > family > width > series > size > > ... > > So keys like "fig / encoding" look quite natural, but it would be > quite useful if a user could set keys also like this: > > set-all, family=... > > set-fig, family=... , size= ... At a technical level, this can be supported. However, my concern is more at the conceptual level. In most programming languages, keyval input is used to replace positional parameters by named ones. On the other hand, the pgfkeys approach inter-mixes named parameters with executed items. At present, the approach in l3keys when setting keys is rather more toward the 'named parameters' approach. Now, it may be that practical considerations mean that something more like the pgfkeys approach is actually the best plan. However, I guess I need a bit more convincing. For example, in siunitx I have a similar issue, and in the end went for something like \keys_define:nn { module } { thing .meta:n = { subgroup-a-thing = #1 , subgroup-b-thing = #1 }, subgroup-a-thing .code:n = ... , subgroup-b-thing .code:n = ... , } but did wonder if \keys_define:nn { module } { thing .meta:n = { subgroup-a / thing = #1 , subgroup-b / thing = #1 }, subgroup-a / thing .code:n = ... , subgroup-b / thing .code:n = ... , } might have been clearer. -- Joseph Wright