Received: from webgate.proteosys.de (mail.proteosys-ag.com [62.225.9.49]) by lucy.proteosys (8.11.0/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id f1KIpV123559 for ; Tue, 20 Feb 2001 19:51:32 +0100 Received: by webgate.proteosys.de (8.11.0/8.11.0) with ESMTP id f1KIpVd00530 . for ; Tue, 20 Feb 2001 19:51:31 +0100 Received: from mail.Uni-Mainz.DE (mailserver1.zdv.Uni-Mainz.DE [134.93.8.30]) by mailgate1.zdv.Uni-Mainz.DE (8.11.0/8.10.2) with ESMTP id f1KIpUH21531 for ; Tue, 20 Feb 2001 19:51:30 +0100 (MET) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C09B6E.240E5200" Received: from mailgate2.zdv.Uni-Mainz.DE (mailgate2.zdv.Uni-Mainz.DE [134.93.8.57]) by mail.Uni-Mainz.DE (8.9.3/8.9.3) with ESMTP id TAA28610 for ; Tue, 20 Feb 2001 19:51:29 +0100 (MET) Received: from mail.listserv.gmd.de (mail.listserv.gmd.de [192.88.97.5]) by mailgate2.zdv.Uni-Mainz.DE (8.11.0/8.10.2) with ESMTP id f1KIpSQ03328 for ; Tue, 20 Feb 2001 19:51:29 +0100 (MET) X-MimeOLE: Produced By Microsoft Exchange V6.5 Received: from mail.listserv.gmd.de (192.88.97.5) by mail.listserv.gmd.de (LSMTP for OpenVMS v1.1a) with SMTP id <0.F51A254B@mail.listserv.gmd.de>; Tue, 20 Feb 2001 19:51:19 +0100 Received: from RELAY.URZ.UNI-HEIDELBERG.DE by RELAY.URZ.UNI-HEIDELBERG.DE (LISTSERV-TCP/IP release 1.8b) with spool id 491612 for LATEX-L@RELAY.URZ.UNI-HEIDELBERG.DE; Tue, 20 Feb 2001 19:50:17 +0100 Received: from ix.urz.uni-heidelberg.de (mail.urz.uni-heidelberg.de [129.206.119.234]) by relay.urz.uni-heidelberg.de (8.8.8/8.8.8) with ESMTP id TAA26930 for ; Tue, 20 Feb 2001 19:50:15 +0100 (MET) Received: from relay.uni-heidelberg.de (relay.uni-heidelberg.de [129.206.100.212]) by ix.urz.uni-heidelberg.de (8.8.8/8.8.8) with ESMTP id TAA17856 for ; Tue, 20 Feb 2001 19:50:14 +0100 Received: from moutvdom00.kundenserver.de (moutvdom00.kundenserver.de [195.20.224.149]) by relay.uni-heidelberg.de (8.10.2+Sun/8.10.2) with ESMTP id f1KIoEx10486 for ; Tue, 20 Feb 2001 19:50:14 +0100 (MET) Received: from [195.20.224.209] (helo=mrvdom02.schlund.de) by moutvdom00.kundenserver.de with esmtp (Exim 2.12 #2) id 14VHrZ-00036r-00 for LATEX-L@urz.uni-heidelberg.de; Tue, 20 Feb 2001 19:50:13 +0100 Received: from manz-3e364803.pool.mediaways.net ([62.54.72.3] helo=istrati.zdv.uni-mainz.de) by mrvdom02.schlund.de with esmtp (Exim 2.12 #2) id 14VHs6-0001Au-00 for LATEX-L@URZ.UNI-HEIDELBERG.DE; Tue, 20 Feb 2001 19:50:46 +0100 Received: (from latex3@localhost) by istrati.zdv.uni-mainz.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) id TAA08388; Tue, 20 Feb 2001 19:47:50 +0100 In-Reply-To: References: Return-Path: X-Mailer: VM 6.75 under Emacs 20.4.1 x-mime-autoconverted: from quoted-printable to 8bit by relay.urz.uni-heidelberg.de id TAA26931 X-Authentication-Warning: istrati.zdv.uni-mainz.de: latex3 set sender to frank@mittelbach-online.de using -f Content-class: urn:content-classes:message Subject: Re: New template macro families Date: Tue, 20 Feb 2001 19:47:50 +0100 Message-ID: <14994.48086.318453.551900@istrati.zdv.uni-mainz.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: From: "Frank Mittelbach" Sender: "Mailing list for the LaTeX3 project" To: "Multiple recipients of list LATEX-L" Reply-To: "Mailing list for the LaTeX3 project" Status: R X-Status: X-Keywords: X-UID: 3998 This is a multi-part message in MIME format. ------_=_NextPart_001_01C09B6E.240E5200 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Lars, > >are you saying that the decision within NFSS was good or bad? > > I'm essentially saying that the decision was good, because I = understood > what that thingy meant (here we switch to font ...) without any > understanding of the mechanisms behind it. (Here I mean in particular = that phhh, good; you got me worried :-) > can contain a period), but for keyvals you've already opened the door = for > miscellaneous symbols by a frequent use of hyphens. well opened the door is perhaps too much to say. if there would be a = decision now to say that template, instances and key names can not contain a = slash or can only contain a...zA...Z- then we could make that decision. mind you i'm not arguing for it. i offered that only as an option = because we used this type of naming convention in the past with good results. > As for splitting the names: You need to do a catcode change when = defining > the macro that is to retrieve the parts of the names, and it's not = (in > complete generality, although probably yes in practice) possible to = get the yes i understand that one can write such a macro in this way. > parts right simply by expanding one macro, but with the current = naming > scheme there might not even be a unique identification of the name = parts. with the current naming convention probably not but we all agree that we = want to replace that, don't we? my remark was only to replace perhaps { and = }{ by / and leave out the final } in the names to get shorter and perhaps more readable names though that certainly open to debate (and probably just a question of being used to) again, you and David decide on something (or even implement it --- you = want the latest sources?) frank > > Lars Hellstr=F6m ------_=_NextPart_001_01C09B6E.240E5200 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: New template macro families

Lars,

 > >are you saying that the decision within = NFSS was good or bad?
 >
 > I'm essentially saying that the decision = was good, because I understood
 > what that thingy meant (here we switch to = font ...) without any
 > understanding of the mechanisms behind it. = (Here I mean in particular that

phhh, good; you got me worried  :-)

 > can contain a period), but for keyvals = you've already opened the door for
 > miscellaneous symbols by a frequent use of = hyphens.

well opened the door is perhaps too much to say. if = there would be a decision
now to say that template, instances and key names can = not contain a slash or
can only contain a...zA...Z- then we could make that = decision.

mind you i'm not arguing for it. i offered that only = as an option because we
used this type of naming convention in the past with = good results.

 > As for splitting the names: You need to do = a catcode change when defining
 > the macro that is to retrieve the parts of = the names, and it's not (in
 > complete generality, although probably yes = in practice) possible to get the

yes i understand that one can write such a macro in = this way.

 > parts right simply by expanding one macro, = but with the current naming
 > scheme there might not even be a unique = identification of the name parts.

with the current naming convention probably not but we = all agree that we want
to replace that, don't we? my remark was only to = replace perhaps { and }{ by /
and leave out the final } in the names to get shorter = and perhaps more
readable names though that certainly open to debate = (and probably just a
question of being used to)

again, you and David decide on something (or even = implement it --- you want
the latest sources?)

frank

 >
 > Lars Hellstr=F6m

------_=_NextPart_001_01C09B6E.240E5200--