LATEX-L Archives

Mailing list for the LaTeX3 project


Options: Use Forum View

Use Proportional Font
Show HTML Part by Default
Condense Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Mailing list for the LaTeX3 project <[log in to unmask]>
Sun, 6 Mar 2011 08:47:25 +0100
Mailing list for the LaTeX3 project <[log in to unmask]>
text/plain; charset=us-ascii
Frank Mittelbach <[log in to unmask]>
text/plain (46 lines)
Joseph Wright writes:
 > On 06/03/2011 04:54, Arno Trautmann wrote:
 > > Hi all,
 > > 
 > > maybe a stupid question, but is there a reason that there are no
 > > variants for the coffin functions like the :c type?
 > > I want to make use of a counter in coffins names, and :c would make life
 > > much more easier than using \expandafter. Or is there another, yet more
 > > elegant way to use a counter in the macro name?
 > > 
 > > cheers
 > > Arno
 > It's not 100 clear yet, but the initial plan at least for me is that
 > coffins are a design-level construct. That means that \NewCoffin is the
 > way to produce coffins - \coffin_new:N is there mainly to be wrapped up
 > in a design-level function.
 > 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. 

On document level, you are right, \NewCoffin should be enough but if you 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

But one general comment here Arno: the expl language and its arg
"preprocessing" concept was explicitly designed so that any variant from a
base function could be added by any package if necessary. So there is never
ever a need to use \exp_after:wN. Instead, if you miss a variant you simply
provide it via

\cs_generate_variant:Nn \coffin_new:N { c }

Have a look at the discussion in l3expan.dtx

Especially with functions that have many arguments we often only provide a few
variants that we forsee to be generally useful. Over time, missing variants,
if they turn out to be needed more often, can always be moved to the kernel
at some point.

Executing \cs_generate_variant:Nn is very light-weight, so it doesn't hurt
much if several packages provide the same variant