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> <4D73663A.5020508@gmx.de>
            <4D737EC5.5090809@morningstar2.co.uk>
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigFE95EEDFA25D7B596AB14D81"
Message-ID:  <4D738308.2030500@gmx.de>
Date:         Sun, 6 Mar 2011 13:50:16 +0100
Reply-To: Mailing list for the LaTeX3 project
              <LATEX-L@listserv.uni-heidelberg.de>
Sender: Mailing list for the LaTeX3 project <LATEX-L@listserv.uni-heidelberg.de>
From: Arno Trautmann <Arno.Trautmann@GMX.DE>
Subject: Re: \coffin_new:c ?
To: LATEX-L@listserv.uni-heidelberg.de
In-Reply-To:  <4D737EC5.5090809@morningstar2.co.uk>
Precedence: list
Status: R

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigFE95EEDFA25D7B596AB14D81
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Joseph Wright wrote:
> On 06/03/2011 10:47, Arno Trautmann wrote:
>>> When I rewrote the coffins code, I originally included "c" variants, =
but
>>> 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 shou=
ld
>>> be done for consistency. This is the work of 5 minutes: shall I make =
the
>>> 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 shou=
ld
>> not be handled this way.
>=20
> As I said, what would be nice is an idea of the context. It may well be=

> that we need the "c" variants: after all, until people try these things=

> out then it's hard to know.

Ok, to go into detail: I wrote a class for typesetting flashcards to
prepare for exams. The user writes something like

\card
question1

answer1

etc. The blank lines are just to minimize writing effort. The questions
are then set on the front side of a paper, the answers on the back side.
Now, question and answer have to fit together, so I have to store
content in boxes and putting them in the correct order onto a grid on
both sides of a page.
Using LaTeX2=CE=B5, I stored the content in macros with names given by a
counter (question@page) that is raised for every question on one page:

\expandafter\def\csname answer@\thequestion@page \endcsname{#3}

and placed them using minipages and reversed textdirection (rtl) for the
answers. That was not very robust and the code looks ugly, so I am
looking for a more stable way and coffins seem to be helpful here.

Hope this is enough information; the code is on github:
https://github.com/alt/lernkarten

cheers
Arno


--------------enigFE95EEDFA25D7B596AB14D81
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/

iEYEARECAAYFAk1zgwgACgkQcYXUw/rerZ4XWQCcCjMzGutZvInEwtf4i6LRYhis
mZQAn3VohvcYoUQiG9tEOCkCvFfTQwZ0
=1+Tq
-----END PGP SIGNATURE-----

--------------enigFE95EEDFA25D7B596AB14D81--