## LATEX-L@LISTSERV.UNI-HEIDELBERG.DE

 Options: Use Classic View Use Monospaced Font Show Text Part by Default Show All Mail Headers Topic: [<< First] [< Prev] [Next >] [Last >>]

 Re: Templates Frank Mittelbach <[log in to unmask]> Mon, 29 Jan 2001 09:03:17 +0100 text/plain (161 lines) Lars,  > 1. The order of parameter assignments.  >  > I haven't seen anything in the documentation about in which order the code  > for the various keys get executed, but in the implementation it looks as if  > they are executed in the order they are listed. i guess this is something for David to comment on, my memory is a bit hazy the very first drafts of the template interface (where there was still something like DeclareCommandInstance and other stuff) we tried to be able to use key values inside an instance for specifying the values of other keys, eg  baselineskip = 12pt,  topskip = 10pt,  textheight = \baselineskip * 49 + \topskip, but first of all we never came up with a good way to reference keys on the right hand side and then there was the problem this concept only worked for certain key types and (forgotten what) and ... so basically that idea was abandomed again, though there might be some traces left in the code I fear. As it looks right now it seems to like this:  - default values are executed first order of specification at template    level (unless overwritten)  - instance values executed thereafter and in order of specification    at instance level this is from looking at the following example: \RequirePackage{template} \RequirePackage{trace} \DeclareTemplateType{xxx}{0} \def\MultiSelection{\MultiSelectionError} %\def\foo{bar} %\traceon \DeclareTemplate{xxx}{test}{0}  {   xkey=n [\foo] \xkey,   ykey=n [\Delayevaluation\foo] \ykey,   zkey=n \zkey,   last=n [last] \lastkey  }  {    \DoParameterAssignments    abc  } \ShowTemplate{xxx}{test} \DeclareInstance{xxx}{bar}{test}  {   zkey = foo,   xkey = baz  } \DeclareInstance{xxx}{baz}{test}  {   last = first,   zkey = foo  } \ShowInstance{xxx}{bar} \ShowInstance{xxx}{baz} ---------------------------------------------- which gives: (./template-test.tex LaTeX2e <2000/06/01> Babel and hyphenation patterns for english, french, german, ngerman, du mylang, nohyphenation, loaded. (./template.sty (./ldcsetup.sty (/cdrom/texmf/tex/latex/graphics/keyval.sty) (/usr/local/texmf/tex/latex/tools/calc.sty))) (./trace.sty) ******* Template: xxx/test ******* * * Defaults: * \TPD>/xxx/test=macro:->\KV@xxx/test@last {\def \lastkey {last}}\KV@xxx/test@yk ey {\def \ykey {\Delayevaluation \foo }}\KV@xxx/test@xkey {\def \xkey {\foo } } * * Restrictions: * \TPR>/xxx/test=\relax * * Body: * > \TP>/xxx/test=\long macro: -> \DoParameterAssignments abc . \TP>/xxx/test l.22 \ShowTemplate{xxx}{test} ? ******* Instance: <>xxx/bar ******* * > \<>xxx/bar=macro: ->\TP@assignments {\def \ykey {\Delayevaluation \foo }\def \lastkey {last}\de f \zkey {foo}\def \xkey {baz}}\TP>/xxx/test . \<>xxx/bar l.36 \ShowInstance{xxx}{bar} ? ******* Instance: <>xxx/baz ******* * > \<>xxx/baz=macro: ->\TP@assignments {\def \xkey {\foo }\def \ykey {\Delayevaluation \foo }\def  \lastkey {first}\def \zkey {foo}}\TP>/xxx/test . \<>xxx/baz l.37 \ShowInstance{xxx}{baz} ? x -------------------------------------------------------------  > It would be nice if this  > could be put in writing since you sometimes need one assignment to be  > carried out before another (my concrete example of this is that an instance  > key gets used in code for an s' key). perhaps the above semantics could be made a formal specification though it would need to be checked whether this is true for all key types. As I said my recollection is that in the end the feeling was that we can't rely on order of specification (though even that would need formal specification)  > 2. The nature of the n' key type  >  > Are n' keys evaluated (expanded) at declaration-time or not? template.dtx  > is actually contradicting itself on this matter: in Section 1 it says n'  > is the same thing as f0', but in Subsection 3.1 there is an example using  > \DelayEvaluation in the default for a type n' key to avoid  > declaration-time evaluation. As far as I can tell the implementation takes  > a third position as it parses a \MultiSelection but otherwise leaves the  > code unevaluated. section 3.1 is rubbish and perhaps due to a bug that i just noticed trying the code. the code indeed looks for \MultiSelection but since MultiSelection is an undefined csname the test via \expandafter\ifx\@car dies a horrible death if you do   key =n [\foo] \key and \foo is undefined (since that is then = to \MultiSelection) this is why the above sample code eactually \def's \MultiSelection have to run to earn some bread and butter (more on that tonight) frank