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 p7RLu8AM024545 for ; Sat, 27 Aug 2011 23:56:09 +0200 Received: (qmail 23586 invoked by alias); 27 Aug 2011 21:56:03 -0000 Delivered-To: GMX delivery to rainer.schoepf@gmx.net Received: (qmail invoked by alias); 27 Aug 2011 21:56:03 -0000 Received: from relay.uni-heidelberg.de (EHLO relay.uni-heidelberg.de) [129.206.100.212] by mx0.gmx.net (mx042) with SMTP; 27 Aug 2011 23:56:03 +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 p7RLrInD002337 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 27 Aug 2011 23:53:19 +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 p7RCBACF002634; Sat, 27 Aug 2011 23:53:18 +0200 Received: by LISTSERV.UNI-HEIDELBERG.DE (LISTSERV-TCP/IP release 16.0) with spool id 1603786 for LATEX-L@LISTSERV.UNI-HEIDELBERG.DE; Sat, 27 Aug 2011 23:53:18 +0200 Received: from relay.uni-heidelberg.de (relay.uni-heidelberg.de [129.206.100.212]) by listserv.uni-heidelberg.de (8.13.1/8.13.1) with ESMTP id p7RLrIuj013016 for ; Sat, 27 Aug 2011 23:53:18 +0200 Received: from lon1-post-3.mail.demon.net (lon1-post-3.mail.demon.net [195.173.77.150]) by relay.uni-heidelberg.de (8.14.1/8.14.1) with ESMTP id p7RLr98x002305 for ; Sat, 27 Aug 2011 23:53:12 +0200 Received: from morningstar2.demon.co.uk ([80.176.134.7] helo=palladium.local) by lon1-post-3.mail.demon.net with esmtp (Exim 4.69) id 1QxQnu-0003lF-ey for LATEX-L@LISTSERV.UNI-HEIDELBERG.DE; Sat, 27 Aug 2011 21:53:09 +0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; 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> <4E53D7B6.80109@morningstar2.co.uk> X-Enigmail-Version: 1.3.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Message-ID: <4E596725.5050900@morningstar2.co.uk> Date: Sat, 27 Aug 2011 22:52:37 +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: Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-GMX-Antispam: 0 (Sender is in whitelist: joseph.wright@MORNINGSTAR2.CO.UK); Detail=5D7Q89H36p4L00VTXC6D4q0N+AH0PUCnBi0P5cROEGjO+pG7NAH/K+tf9SrVFtpLrKONl 2T9EL4W4U4jgzLbnCcGpk1z/zwmKT/K1fv3lD0=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: 6836 On 23/08/2011 18:29, Ulrike Fischer wrote: >>> 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. > > chessboard is doing it too. Once I got the knack on defining keys it > came quite naturally to use them not only to set width or size but > also to put and remove pieces, declare a color in one key, and with > the next key draw a rule in this color. > > I realized only at the end that this was an quite unusual use of > keyval syntax. > > A "change path" command would be really useful here. Currently every > key must have an unique name, and this can give quite long names. > > >> At present, the approach in l3keys when setting keys is rather more >> toward the 'named parameters' approach. > > This is also the case with xkeyval and it could be used for the > other approach too ;-) I think l3keys is very powerful and quite fun > to use. I suspect that we may want the 'executable' key idea, for example .cd, at some stage. This plus '.style' is part of why pgfkeys works so well. I will probably look to add this in as experimental stuff to l3keys at some stage (soon-ish). -- Joseph Wright