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