Print

Print


A few comments on Achim nice piece of work:

 > %   This template starts a new environment, typesets the head of a
 > %   theorem, and sets fonts for the body of the theorem. The
 > %   environment is ended by an \verb|\@endtheorem| command.

in my implementation for lists (not ready yet) I used something like
\EndThisList to denote the reference to the code. The idea is that that
pointer should appear in places used class designers building document
commands from templates and xparse. Now that should in my opinion be
distinguisable from coding actions (eg stuff that needs @ in names) but at the
same time should clearly also be distinguishable from stuff which is part of a
document. Syntaxwise our idea was to give those class commands mixed-case
names (not all people like that idea but so far we found that it gives a nice
middle layer)

for the theoremstyle template type a good name could then be something like
\EndThisTheorem.

what is perhaps more important is that such a command is actually dependent on
the template chosen. For this reason it can't be defined globally as done by
Achim. After all, somebody else might define a template for this type which
does not use trivlist at all (okay, okay, one could have a default definition
and overwrite it only in templates which can't make use of this but while this
might work in this case it will produce havoc with templates that could be
nested as you will imagine). So I think a safer approach is to explicitly
define the meaning of this command as part of the template definition.

 > % \paragraph{Problem.}
 > % The current solution for `head-format' is very clumsy. Perhaps it would
 > % be better to pass just the name of a template which does the layout
 > % instead of the actual code.

i guess this observation is correct and we should provide some sort of heading
templates that could be used in that place. This will get easier onces my long
promised galley stuff will be ready. For the moment i think it is enough to
get what you want even though it might be more complicated than necessary.

more interesting at the moment seems to me the question i've already posed
with regards to toc entries:

 - what kind of layouts are desirable which cannot be produced by this
   template

 - are the keys adequate (should they be named differently, should there be
   additional ones, others ...)

frank