Received: from mail.proteosys.com ([213.139.130.197]) by nummer-3.proteosys with Microsoft SMTPSVC(6.0.3790.3959); Fri, 21 Aug 2009 08:09:46 +0200 Received: by mail.proteosys.com (8.14.3/8.14.3) with ESMTP id n7L69kVN018821 for ; Fri, 21 Aug 2009 08:09:46 +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 n7L65PsU008540 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 21 Aug 2009 08:05:25 +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 n7KM1YVC008874; Fri, 21 Aug 2009 08:05:24 +0200 Received: by LISTSERV.UNI-HEIDELBERG.DE (LISTSERV-TCP/IP release 15.5) with spool id 286133 for LATEX-L@LISTSERV.UNI-HEIDELBERG.DE; Fri, 21 Aug 2009 08:05:24 +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 n7L65ORX015117 for ; Fri, 21 Aug 2009 08:05:24 +0200 Received: from rv-out-0708.google.com (rv-out-0708.google.com [209.85.198.249]) by relay2.uni-heidelberg.de (8.13.8/8.13.8) with ESMTP id n7L65JJ3008487 for ; Fri, 21 Aug 2009 08:05:23 +0200 Received: by rv-out-0708.google.com with SMTP id c5so154619rvf.10 for ; Thu, 20 Aug 2009 23:05:19 -0700 (PDT) Received: by 10.141.18.5 with SMTP id v5mr367791rvi.254.1250834719533; Thu, 20 Aug 2009 23:05:19 -0700 (PDT) Received: from ?129.127.15.244? ([129.127.15.244]) by mx.google.com with ESMTPS id l31sm2195256rvb.4.2009.08.20.23.05.17 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 20 Aug 2009 23:05:18 -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> X-Mailer: Apple Mail (2.935.3) X-Spam-Whitelist: Message-ID: Date: Fri, 21 Aug 2009 15:35:13 +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: <4A8E304C.4050208@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 06:09:46.0854 (UTC) FILETIME=[FBE28060:01CA2225] Status: R X-Status: X-Keywords: X-UID: 5965 On 21/08/2009, at 2:57 PM, Joseph Wright wrote: > Will Robertson wrote: >> I imagine markup like >> >> \EditInstance{sectioning}{chapter}% template is implicit! >> { ...keyvals... } >> >> but I don't know if my desire for this construct illustrates a >> misunderstanding of mine of the system. On second thought, I just realised that you need to know what template is being used in order to know which keyvals you want to change. The above could just as well, then, be \EditInstance{sectioning}{starts-new-page}{chapter} { ...keyvals... } > From Frank's explanation, my understanding is slightly different. The > key is to remember where templates it into all of this. Taking my > example from before, and sticking with the current naming scheme, we > might have > > \DeclareTemplateType { sectioning } 3 > \DeclareTemplate { sectioning } { starts-new-page } 3 > { { } > \DeclareTemplate { sectioning } { space-before-and-after } > { { } > \DeclareRestrictedTemplate { sectioning } > { starts-new-page-no-number } { starts-new-page } > { } > \DeclareInstance { sectioning } { chapter } { starts-new-page } > { } > \DeclareCollectionInstance { frontmatter } { sectioning } > { chapter } { starts-new-page-no-number } > { } > > \DeclareDocumentCommand \chapter { s o m } { > % Code to include > \UseInstance { sectioning } { chapter } > } So far I agree with all this :) If this is how Frank sees how templates should be used, then I think we're all on the same page. > If I'm designing a document and want to completely change \chapter, I > have a few options: > > 1) If one of the existing templates can do what I want with the right > keyval settings, I re-declare the instance. So if I want to alter font > sizes and so on but not more general layout, I do > > \DeclareInstance { sectioning } { chapter } { starts-new-page } > { } > > plus probably > > \DeclareCollectionInstance { frontmatter } { sectioning } > { chapter } { starts-new-page-no-number } > { } Right, and I also agree with your other proposals for when you want to change things more radically. But... > In all three cases, the document command is left alone. (I think this is the desirable approach.) > Of course, this > leaves open the question of how much variation each template leaves > open. I can see your argument for creating instances with only minor > adjustments from existing ones ("All I want to do is change length a > to > length b, leaving everything else alone."). My feeling is that the > idea > is that document classes should be much clearer on the settings they > use, so the cost of copying a template and altering only a few lines > is > worth it in clarity of what is going on. ...sometimes there are simply lots of settings to adjust! :) Something like a single section heading template could feasibly have - number size & font - title size & font - title paragraph shape - number indent - number-to-title skip - pre-material (penalty & skip & possible rule) - post-material (ditto) I agree that most of these *should* be reset when any of them are, but sometimes you just want to change the pre/post-skip or whatever, and I don't think it's convenient to have to find the definition of the instance and copy/paste the whole thing. > The danger of allowing > something like \EditInstance is that you can easily get back to ad hoc > changes here and there with no clear separation of design and > document code. Provided that the \EditInstance goes together with the other customisations for the document, I don't really see how this blurs the line between the two. Isn't it just a more convenient way to completely redeclare the instance without knowing the original settings? But maybe you're right, and I'm trying to add a feature to solve a problem that is better solved in another way (e.g., by declaring more and more restricted templates and redefining the instances from scratch as you suggest). Will