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 p26Anc8R023616 for ; Sun, 6 Mar 2011 11:49:40 +0100 Received: (qmail 8033 invoked by alias); 6 Mar 2011 10:49:33 -0000 Delivered-To: GMX delivery to rainer.schoepf@gmx.net Received: (qmail invoked by alias); 06 Mar 2011 10:49:32 -0000 Received: from relay.uni-heidelberg.de (EHLO relay.uni-heidelberg.de) [129.206.100.212] by mx0.gmx.net (mx054) with SMTP; 06 Mar 2011 11:49:32 +0100 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 p26AleJO005812 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 6 Mar 2011 11:47:40 +0100 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 p25N146Z025519; Sun, 6 Mar 2011 11:47:35 +0100 Received: by LISTSERV.UNI-HEIDELBERG.DE (LISTSERV-TCP/IP release 16.0) with spool id 1206592 for LATEX-L@LISTSERV.UNI-HEIDELBERG.DE; Sun, 6 Mar 2011 11:47:35 +0100 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 p26AlZPT023264 for ; Sun, 6 Mar 2011 11:47:35 +0100 Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by relay2.uni-heidelberg.de (8.13.8/8.13.8) with SMTP id p26AlNhv024035 for ; Sun, 6 Mar 2011 11:47:27 +0100 Received: (qmail invoked by alias); 06 Mar 2011 10:47:23 -0000 Received: from HSI-KBW-091-089-142-083.hsi2.kabel-badenwuerttemberg.de (EHLO [192.168.0.197]) [91.89.142.83] by mail.gmx.net (mp051) with SMTP; 06 Mar 2011 11:47:23 +0100 X-Provags-ID: V01U2FsdGVkX199G6x+lsN9k0967KJYqAg984B4+lcCzmyEd37UDF o4TiHDwBrWDtY+ User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.14) Gecko/20110301 Lanikai/3.1.8 MIME-Version: 1.0 References: <4D731368.1060701@gmx.de> <4D7335FC.3050007@morningstar2.co.uk> <19827.15373.437917.416434@morse.mittelbach-online.de> <4D735487.8070809@morningstar2.co.uk> X-Enigmail-Version: 1.1.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigD6B0DDE8B49EE8951CF4BF4F" Message-ID: <4D73663A.5020508@gmx.de> Date: Sun, 6 Mar 2011 11:47:22 +0100 Reply-To: Mailing list for the LaTeX3 project Sender: Mailing list for the LaTeX3 project From: Arno Trautmann Subject: Re: \coffin_new:c ? To: LATEX-L@listserv.uni-heidelberg.de In-Reply-To: <4D735487.8070809@morningstar2.co.uk> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-GMX-Antispam: 0 (Mail was not recognized as spam); Detail=5D7Q89H36p4WX0t+AtsdW/aoqQDaDNIQmQ42YRl1sCMKAaj1x11eY3UOezDsDXYNS66rN u8rTyvHv5XL0bJ52jvUl1dRN738ezJhno1IOlGQnfXGBxmzBp+cBX3yWoRbg1HC0+bptHPMryLmv M3uulOGGAligEi3V1; 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: 6631 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigD6B0DDE8B49EE8951CF4BF4F Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Joseph Wright wrote: > On 06/03/2011 07:47, Frank Mittelbach wrote: >> > It's not 100 clear yet, but the initial plan at least for me is tha= t >> > coffins are a design-level construct. That means that \NewCoffin is= the >> > way to produce coffins - \coffin_new:N is there mainly to be wrappe= d up >> > in a design-level function. >> >=20 >> > Perhaps you might illustrate what you're doing at a 'concept' level= ? >> >> in my opinion it should be there, so I would call it an oversight.=20 >> >> On document level, you are right, \NewCoffin should be enough but if y= ou build >> a package that involves coffins it is possible that the names of that = coffin >> are build from other structures, so that you wan to use :c to produce = them Yes, that's exactly my case here. To be more verbose, I want to do something like (pseudo code): for i =3D 1,30 do \coffin_new:c{pkg i coffin} end to generate 30 individual coffins that later can be adressed and processed in the same way. Frank, thanks for pointing me at \cs_generate_variant:Nn; I already foudn it but was not sure if this was the best way to go. > When I rewrote the coffins code, I originally included "c" variants, bu= t > decided to leave them out pending seeing whether they were needed. I've= > no objection to them, I was just trying to avoid 'variant overkill'. > Note that if you allow "c"-type names, then it's not just \coffin_new:N= > that needs variants. All of the 'code-level interface' functions should= > be done for consistency. This is the work of 5 minutes: shall I make th= e > change? If no one else has needed it so far, I'll just add it to my package. I only asked to see if there was a special reason that coffin names should not be handled this way. Thanks for your replies, Arno --------------enigD6B0DDE8B49EE8951CF4BF4F Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk1zZjoACgkQcYXUw/rerZ6S3wCgqq7YfyB+8W2fis1dPaCkOwXX 9OMAn1KOKsky8Ysa6mr/DPgpXWL8Fz0X =bRVy -----END PGP SIGNATURE----- --------------enigD6B0DDE8B49EE8951CF4BF4F--