LATEX-L Archives

Mailing list for the LaTeX3 project


Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

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

Print Reply
Frank Mittelbach <[log in to unmask]>
Reply To:
Mailing list for the LaTeX3 project <[log in to unmask]>
Tue, 6 Feb 2001 21:41:24 +0100
text/plain (55 lines)
David Carlisle writes:

 > There is a general rule of optional things using {} and mandatory things
 > using [] but perhaps since the syntax for template declarations are so

you meant the other way around do you?

 > formalised anyway, the rules can be different here. Frank? Chris?

they could i have to deep feelings here.

actually in practice defaults set up this way are far less efficient than
coding them in the body of the template though for serious template writing i
started to avoid using them.

but that doesn't mean that it we should not have them. for the less
experienced writer spcifying defaults up at the top is a) easier to specify
and b) easier to modify and c) visually easier to capture and understand.

however, my goal would be that on top of a good selection of templates you
have something like lynx sitting and allowing you to produce instances etc
from a gui interface. with a formalised description block (not existing yet to
that extend) you can even have a generic gui interface that can handle any
template file and provides sensible documentation on what can be specified and
changed to produce instances thereoff.

so yes, in my opinion, the most important factor is that the syntax is strict
and not that it resembles LaTeX body syntax.

 > > The difference between a template and an instance could be explained
 > > better.
 > ah documentation. Yes that could be improved.

well, i would say it could be written. actually what is needed is a real a
article about it. perhaps for tugboat

 > I agree that it should be cleaned up. Hopefully though those internal
 > names can be changed without really affecting the main interface
 > or packages using it.

i think it can. and i would be really happy if Lars and or anybody else
continues with finding further snags and then we should try at getting it to
the next level.

 > Thanks again for your detailed reading of the code. It is heartening
 > to have someone say that it is basically a good idea, modulo some
 > technical "features". There's always a danger that nobody likes
 > it at all:-)

isn't that true

good night (up since 4:50am and i'm gettin' ....)