Received: via tmail-4.1(11) (invoked by user schoepf) for schoepf; Mon, 3 Jan 2000 22:46:14 +0100 (MET) Received: from mailgate2.zdv.Uni-Mainz.DE (mailgate2.zdv.Uni-Mainz.DE [134.93.8.57]) by mailserver1.zdv.Uni-Mainz.DE (8.9.3+Sun/8.9.1) with ESMTP id WAA19410 for ; Mon, 3 Jan 2000 22:46:14 +0100 (MET) MIME-Version: 1.0 Received: from mail.listserv.gmd.de (mail.listserv.gmd.de [192.88.97.5]) by mailgate2.zdv.Uni-Mainz.DE (8.9.3/8.9.3) with ESMTP id WAA12509 for ; Mon, 3 Jan 2000 22:46:12 +0100 (MET) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF5633.F4CC1700" Received: from mail.listserv.gmd.de (192.88.97.5) by mail.listserv.gmd.de (LSMTP for OpenVMS v1.1a) with SMTP id <1.C6ED372D@mail.listserv.gmd.de>; Mon, 3 Jan 2000 22:46:03 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Received: from RELAY.URZ.UNI-HEIDELBERG.DE by RELAY.URZ.UNI-HEIDELBERG.DE (LISTSERV-TCP/IP release 1.8b) with spool id 447445 for LATEX-L@RELAY.URZ.UNI-HEIDELBERG.DE; Mon, 3 Jan 2000 22:45:03 +0100 Received: from relay.uni-heidelberg.de (relay.uni-heidelberg.de [129.206.100.212]) by relay.urz.uni-heidelberg.de (8.8.8/8.8.8) with ESMTP id WAA14702 for ; Mon, 3 Jan 2000 22:44:03 +0100 (MET) Received: from mailgate1.zdv.Uni-Mainz.DE (mailgate1.zdv.Uni-Mainz.DE [134.93.8.56]) by relay.uni-heidelberg.de (8.9.1b+Sun/8.9.1) with ESMTP id WAA26322 for ; Mon, 3 Jan 2000 22:44:58 +0100 (MET) Received: from mailserver1.zdv.Uni-Mainz.DE (mailserver1.zdv.Uni-Mainz.DE [134.93.8.30]) by mailgate1.zdv.Uni-Mainz.DE (8.9.3/8.9.3) with ESMTP id WAA11825 for ; Mon, 3 Jan 2000 22:45:02 +0100 (MET) Received: from istrati.zdv.uni-mainz.de (dialin407.zdv.Uni-Mainz.DE [134.93.175.107]) by mailserver1.zdv.Uni-Mainz.DE (8.9.3+Sun/8.9.1) with ESMTP id WAA19145 for ; Mon, 3 Jan 2000 22:45:01 +0100 (MET) Received: (from design@localhost) by istrati.zdv.uni-mainz.de (8.9.3/8.9.3) id WAA00547; Mon, 3 Jan 2000 22:45:50 +0100 In-Reply-To: <87a2301a@corona.oche.de> References: <87a2301a@corona.oche.de> Return-Path: x-vm-v5-data: ([nil nil nil nil nil nil nil nil nil]["2377" "Mon" "3" "January" "2000" "22:45:50" "+0100" "Frank Mittelbach" "frank.mittelbach@LATEX-PROJECT.ORG" nil "48" "Re: theorem templates" "^Date:" nil nil "1" nil nil nil nil nil]nil) X-Authentication-Warning: istrati.zdv.uni-mainz.de: design set sender to design@istrati.zdv.uni-mainz.de using -f Content-class: urn:content-classes:message Subject: Re: theorem templates Date: Mon, 3 Jan 2000 22:45:50 +0100 Message-ID: <200001032145.WAA00547@istrati.zdv.uni-mainz.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: From: "Frank Mittelbach" Sender: "Mailing list for the LaTeX3 project" To: "Multiple recipients of list LATEX-L" Reply-To: "Mailing list for the LaTeX3 project" Status: R X-Status: X-Keywords: X-UID: 3492 This is a multi-part message in MIME format. ------_=_NextPart_001_01BF5633.F4CC1700 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 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 ------_=_NextPart_001_01BF5633.F4CC1700 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: theorem templates

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

------_=_NextPart_001_01BF5633.F4CC1700--