Return-Path: Delivered-To: GMX delivery to rainer.schoepf@gmx.net Received: (qmail invoked by alias); 21 Aug 2011 09:20:44 -0000 Received: from relay2.uni-heidelberg.de (EHLO relay2.uni-heidelberg.de) [129.206.210.211] by mx0.gmx.net (mx052) with SMTP; 21 Aug 2011 11:20:44 +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 p7L9IV7G026109 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 21 Aug 2011 11:18:31 +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 p7L8mhx6017027; Sun, 21 Aug 2011 11:18:30 +0200 Received: by LISTSERV.UNI-HEIDELBERG.DE (LISTSERV-TCP/IP release 16.0) with spool id 1545666 for LATEX-L@LISTSERV.UNI-HEIDELBERG.DE; Sun, 21 Aug 2011 11:18:30 +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 p7L9IUoH017321 for ; Sun, 21 Aug 2011 11:18:30 +0200 Received: from lon1-post-2.mail.demon.net (lon1-post-2.mail.demon.net [195.173.77.149]) by relay2.uni-heidelberg.de (8.13.8/8.13.8) with ESMTP id p7L9IJ73026067 for ; Sun, 21 Aug 2011 11:18:23 +0200 Received: from morningstar2.demon.co.uk ([80.176.134.7] helo=palladium.local) by lon1-post-2.mail.demon.net with esmtp (Exim 4.69) id 1Qv4Ad-0000bg-Zi for LATEX-L@LISTSERV.UNI-HEIDELBERG.DE; Sun, 21 Aug 2011 09:18:19 +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> X-Enigmail-Version: 1.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Message-ID: <4E50CD5A.9040304@morningstar2.co.uk> Date: Sun, 21 Aug 2011 10:18: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: <9788A2B7-3E8F-4D2C-A52E-10999BCB59FA@gmail.com> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-GMX-Antivirus: 0 (no virus found) X-GMX-Antispam: 5 (BackTrace mail analyze); Detail=5D7Q89H36p4L00VTXC6D4q0N+AH0PUCnGL2vqOgpaBYL16oitsMrgDt/NQNpSCZF7bt5n WT2HM38qZ+yU5w+iHvA3v93jaZZ8PxzXORtc8oAXMLnKHDlVA==V1; Status: R X-Status: X-Keywords: X-UID: 6810 On 21/08/2011 08:41, Will Robertson wrote: >> I'd agree that this may not be ideal in this particular case, as choices >> are somewhat different from other ideas. I'm happy to make this switch >> if it feels overall more 'natural' to do ".choices:nn". After all, the >> entire idea of l3keys is to make defining key-value input as easy as >> possible. > > I think it's worth trying out, but I'd prefer it if I wasn't the only one saying it was a good idea. I think this has been raised before, actually. I've never been 100% happy with .generate_choices: anyway. I'll add a function as an experimental addition, in case we need to change it again. Perhaps ".autochoices:nn" to reflect the fact that choices can also be made manually? > While we're talking about .choices: I should mention another item that popped into my head. Would it be worth having another key function along the lines of ".add_choice:n {...}" so you could write > > \keys_define:nn {foo} > { > bar .choices_code:n {...} , > bar .generate_choices:n {a,b,c} > } > ... > \keys_define:nn {foo} % perhaps inside some user-facing code > { > bar .add_choice:n {d} > } > > ? The idea being that key choices could be extensible. Again, I'm not 100% sure this is even a good idea, but it's something that I kinda do in fontspec (for adding new font features), although it's not a major part of the code. (And I can also use the manual choice generation code to implement, so it's not critical.) Life gets a bit complicated tracking which option number is which if you do this. I think in a case such as this I'd favour sticking to making choices manually, as the additional benefit does not seem to balance out with the complexity. >> \keys_if_choice_exist_p:nnn { }{ } >> { } > > I'd be happy with always returning false here -- I don't think a warning or error message would be very helpful in the long run although I could be mistaken. (A case where Morten's "TFE" signature might have come in handy.) Added to code: this one seems non-controversial enough. >>> 4. >>> >>> Implicit mapping for multiple key choices; what do you think the expected behaviour is here? >>> >>> \keys_define:nn {foo} >>> { >>> key .choice: , >>> key / aaa .code:n = \typeout{aaa} , >>> key / bbb .code:n = \typeout{bbb} , >>> } >>> \keys_set:nn {foo} {key={aaa,bbb}} >>> >>> I would be inclined to disallow "," inside a choice name (if that's not already the case) and automatically map over this list. Is this a bad idea? (Of course, happy to do this manually in my own code.) >> >> Here I'm a bit confused. The idea of a multiple-choice key is that they >> are mutually-exclusive. I guess that you have a particular use case in >> mind here, but I wonder if that means you have some badly-defined keys. >> Could you give more detail on this? > > I suppose fontspec is a little odd in its keyval approach when viewed through this lens. It's perfectly reasonable (in fontspec!) to write options like > > [Numbers={OldStyle,Proportional}] To me, this looks like a meta-option of two boolean choices. We don't currently have a 'meta-in-other-paths', so I'd do something like \keys_define:nn { fontspec } { Numbers .code:n = \keys_set:nn { fontspec / Numbers } {#1} } \keys_define:nn { fontspec / Numbers } { OldStyle .bool_set:N = \l_fontspec_Numbers_OldStyle_bool , Proportional .bool_set:N = \l_fontspec_Numbers_Proportional_bool , } Perhaps we need something like ".multichoice:", which would do the same as the above automatically. (This is not that disimilar to what .choice: does.) (Still need to come back on point 3.) -- Joseph Wright