Received: from mail.proteosys.com ([213.139.130.197]) by nummer-3.proteosys with Microsoft SMTPSVC(6.0.3790.3959); Fri, 21 Aug 2009 10:46:31 +0200 Received: by mail.proteosys.com (8.14.3/8.14.3) with ESMTP id n7L8kVdf026869 for ; Fri, 21 Aug 2009 10:46:31 +0200 Received: from listserv.uni-heidelberg.de (listserv.uni-heidelberg.de [129.206.100.94]) by relay2.uni-heidelberg.de (8.13.8/8.13.8) with ESMTP id n7L8gFj4024732 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 21 Aug 2009 10:42:16 +0200 Received: from listserv.uni-heidelberg.de (localhost.localdomain [127.0.0.1]) by listserv.uni-heidelberg.de (8.13.1/8.13.1) with ESMTP id n7L7tNji008874; Fri, 21 Aug 2009 10:42:10 +0200 Received: by LISTSERV.UNI-HEIDELBERG.DE (LISTSERV-TCP/IP release 15.5) with spool id 287045 for LATEX-L@LISTSERV.UNI-HEIDELBERG.DE; Fri, 21 Aug 2009 10:42:10 +0200 Received: from relay2.uni-heidelberg.de (relay2.uni-heidelberg.de [129.206.210.211]) by listserv.uni-heidelberg.de (8.13.1/8.13.1) with ESMTP id n7L8gAdp027048 for ; Fri, 21 Aug 2009 10:42:10 +0200 Received: from rv-out-0708.google.com (rv-out-0708.google.com [209.85.198.250]) by relay2.uni-heidelberg.de (8.13.8/8.13.8) with ESMTP id n7L8g5pZ024363 for ; Fri, 21 Aug 2009 10:42:08 +0200 Received: by rv-out-0708.google.com with SMTP id c5so184117rvf.10 for ; Fri, 21 Aug 2009 01:42:01 -0700 (PDT) Received: by 10.141.3.4 with SMTP id f4mr488004rvi.163.1250844121416; Fri, 21 Aug 2009 01:42:01 -0700 (PDT) Received: from ?129.127.15.244? ([129.127.15.244]) by mx.google.com with ESMTPS id f42sm2812902rvb.52.2009.08.21.01.41.58 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 21 Aug 2009 01:42:00 -0700 (PDT) Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) References: <874332F9-007B-4945-87D5-48B28BBC11CC@gmail.com> <4A8E304C.4050208@morningstar2.co.uk> <4A8E4FF9.1080100@morningstar2.co.uk> X-Mailer: Apple Mail (2.935.3) X-Spam-Whitelist: Message-ID: <4B00C642-FF95-4CF7-9445-2C1C1CCF0904@gmail.com> Date: Fri, 21 Aug 2009 18:11:54 +0930 Reply-To: Mailing list for the LaTeX3 project Sender: Mailing list for the LaTeX3 project From: Will Robertson Subject: Re: template customising To: LATEX-L@LISTSERV.UNI-HEIDELBERG.DE In-Reply-To: <4A8E4FF9.1080100@morningstar2.co.uk> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-ProteoSys-SPAM-Score: -6.599 () BAYES_00,RCVD_IN_DNSWL_MED X-Scanned-By: MIMEDefang 2.65 on 213.139.130.197 Return-Path: owner-latex-l@LISTSERV.UNI-HEIDELBERG.DE X-OriginalArrivalTime: 21 Aug 2009 08:46:31.0926 (UTC) FILETIME=[E1BE9960:01CA223B] Status: R X-Status: X-Keywords: X-UID: 5968 On 21/08/2009, at 5:12 PM, Joseph Wright wrote: > No, I'd agree. There is something of a balancing act to do here, at > least without something like \EditInstance (I'd suggest > \EditInstanceFromTemplate based on my suggestion that > \DeclareInstanceFromTemplate is more accurate than just > \DeclareInstance). I prefer the shorter names simply for brevity. I think with good documentation the ideas behind type -> template -> instance should be concrete enough that the macro names don't need to be that explicit. As long as we give clear examples I think this will be the case. Note that the current documentation is a little more abstract in its descriptions such that it took a couple of read-throughs before you and I (anyway) were thinking about the terms in the same way. I think that's more of a documentation problem than a macro name problem. (Not that I'm against renaming things if you like!) > I imagine that we will end up providing one or more very general > templates with some restricted ones to solve at least parts of the > issue. One question that I should just test on my own before asking is "do restricted templates cascade?" (...testing...) And the answer is no: \documentclass{article} \usepackage{template} \begin{document} \DeclareTemplateType{xxx}{0} \DeclareTemplate{xxx}{test}{0} { xkey=n \xkey, ykey=n \ykey, zkey=n \zkey, } { \DoParameterAssignments (x: \xkey)(y: \ykey)(z: \zkey) } \DeclareRestrictedTemplate{xxx}{test2}{test}{xkey=a} \DeclareRestrictedTemplate{xxx}{test3}{test2}{ykey=b} \DeclareInstance{xxx}{bar}{test3}{zkey = c} \UseInstance{xxx}{bar} \DeclareRestrictedTemplate{xxx}{test2}{test2}{xkey=A} \UseInstance{xxx}{bar} \end{document} The first \UseInstance has xkey and ykey set by the restricted templates 'test2' and 'test3', respectively. If we then use \DeclareRestrictedTemplate to "edit" the 'test2' template then the 'bar' instance does not change. So templates should be considering somewhat "immutable" and perhaps \DeclareRestrictedTemplate should call a warning if attempted to redefine an existing template as in the example above. (Else templates themselves could keep track of their instances and push down the changes to each of their instances if a template is edited -- which would actually involve just re-instantiating the instance with the original parameters -- but that seems rather mad to me.) > So you might imagine > > \DeclareTemplate { sectioning } { std-complete-customisation } ... > > \DeclareRestrictedTemplate { sectioning } > { std-font-variable } { std-complete-customisation } > \DeclareRestrictedTemplate { sectioning } > { std-spacing-variable } { std-complete-customisation } > > where we put all of the possible changes in the first one then cut > down > on the possibles in the second one. The problem being, now, that std-font-variable can't change its spacing, and std-spacing-variable can't change its font :) That seems an odd trade-off to make; how would you ever choose which instance should be put into the document? Since templates don't cascade (i.e., changes to higher templates don't flow on to templates and instances down the line) the idea of a restricted template seems more limited to cases when you literally need to restrict setting certain parameters in order to keep the template (or, rather, the design that the template produces) working. > There is also the point that the template values will probably have a > default. So if you only want to change one thing from what is "out of > the box" then you only need > > \DeclareInstance { type } { name } { template } > { one-changed-key = value } > > The problem only comes if you want to change a few keys in an instance > that already sets several things in the template. Thinking about things more, I think you're right that the defaults of the template are likely to be the parameters that a document's default instance takes. And if they're not the template defaults, they'll be defined in some sort of obvious configuration file. So I'm starting to think that my whole line of questioning is slightly off the mark. Will