User-Agent: Thunderbird 2.0.0.22 (Windows/20090605)
MIME-Version: 1.0
References: <874332F9-007B-4945-87D5-48B28BBC11CC@gmail.com>           
            <4A8E304C.4050208@morningstar2.co.uk>
            <F64AA87D-A646-4C0B-A7B3-57ED46AA5B78@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Message-ID:  <4A8E4FF9.1080100@morningstar2.co.uk>
Date:         Fri, 21 Aug 2009 08:42:49 +0100
Reply-To: Mailing list for the LaTeX3 project
              <LATEX-L@LISTSERV.UNI-HEIDELBERG.DE>
Sender: Mailing list for the LaTeX3 project <LATEX-L@LISTSERV.UNI-HEIDELBERG.DE>
From: Joseph Wright <joseph.wright@MORNINGSTAR2.CO.UK>
Subject: Re: template customising
To: LATEX-L@LISTSERV.UNI-HEIDELBERG.DE
In-Reply-To:  <F64AA87D-A646-4C0B-A7B3-57ED46AA5B78@gmail.com>
Precedence: list
Status: R

Will Robertson wrote:
>> 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.

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 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. 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.

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.

>> 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).

I'm not saying no. Frank will I'm sure have more insight into this, but
I can see that it would be convenient to quickly alter a few settings
from an existing file. That is, after all, how a lot of LaTeX2e classes
are constructed. On the other hand, I suppose you can argue that the
useful thing about forcing each class to be self-contained is that you
are less likely to run into the problem that LaTeX2e has, that lots of
classes make assumptions about the base design that now cannot be changed.
-- 
Joseph Wright