MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
References: <4B671436.4020108@morningstar2.co.uk>
Message-ID:  <19303.19218.784429.433360@morse.mittelbach-online.de>
Date:         Mon, 1 Feb 2010 22:43:46 +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: Frank Mittelbach <frank@MITTELBACH-ONLINE.DE>
Subject: Re: xtemplate and muskips
To: LATEX-L@listserv.uni-heidelberg.de
In-Reply-To:  <4B671436.4020108@morningstar2.co.uk>
Precedence: list
Status: R

Joseph writes:

 > Currently, we have "length" (for a fixed length) and "skip" (for a 
 > rubber length), but nothing which will map to an underlying muskip. I'm 
 > not actually sure we should at the design level 
 > (\DeclareTemplateInterface) but at the code level (\DeclareTemplateCode) 
 > there needs to be some thought. Possibilities:
 > 
 >   - Introduce a new key type (mathskip ?)
 >   - Use a keyword in the code section, as we already do for "global":
 > 
 >      keyname1 = math \l_my_muskip       ,
 >      keyname2 = global math \g_my_muskip,
 >      keyname3 = global \g_some_other_var,
 >      ...
 > 
 >   - Assume that this is rare enough to use a token list to store in
 >     input, and sort out the conversion in the code.
 > 
 > Thoughts? At present, (3) is all that is on offer, but perhaps that is 
 > all we need (do designers care about muskips at all?).

your last question perhaps depends on whether or not there is going to be a
lot of "templates" for math objects which I somehow doubt, mainly because most
such objects will not need a "designer interface" supporting a number of
possible layouts for some object. But I might be wrong.

For non-math objects I don't think that muskips play any role or should play
any role.

From your three options above I don't like option (2) at all --- such a
keyword looks like it can be applied to or combined with others and that isn't
really the case and it isn't the right kind of syntax/semantics. After all the
type is defined on the interface side not on the code side (even though the
code side actually uses a matching storage bin

(1) is my favorite as it is clean and fits the rest of the types.

As you say to implement that it would probably need an underlying support for
muskips as code level types, but you can start by simply having this type
accepting a tokenlist and you deal with it internally for the moment. That
could then later be changed to use whatever the kernel then offers as type
support.

just some initial thoughts

frank