LATEX-L Archives

Mailing list for the LaTeX3 project

LATEX-L@LISTSERV.UNI-HEIDELBERG.DE

Options: Use Classic View

Use Monospaced Font
Show HTML Part by Default
Condense Mail Headers

Topic: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Sender: Mailing list for the LaTeX3 project <[log in to unmask]>
From: Frank Mittelbach <[log in to unmask]>
Date: Wed, 31 Jan 2001 09:01:34 +0100
In-Reply-To: <l03130300b69c3dbf22d7@[130.239.20.144]>
Reply-To: Mailing list for the LaTeX3 project <[log in to unmask]>
Parts/Attachments: text/plain (43 lines)
 > Perhaps a straightforward unprotected \edef isn't right, but a
 > \protected@edef would let through a lot of things which are bad too.
 > Perhaps the right thing would be some kind of \protect@is@[log in to unmask]

shouldn't that be, for the purpose you have in mind rather
\protect@is@string@edef perhaps?

i mean is the purpose is to make a "proper" latex internally usable name then
stringing things is probably the way to go, or not?


 > >that would be an alternative, but again I would like to see at least a single
 > >example why one would need/want expansion (beside gut feeling, though the
 > >latter might be useful)
 >
 > First example: The name value is a mangled general text; then you don't
 > want to mangle it anew each time you use it (especially since you don't
 > know the conditions then will be), but have it stored in a mangled form.

maybe, but could you be more specific in the example, please? i mean can you
really see a practical need (not an abstract one)

 > Second example: I suspect that there will be a number of instances declared
 > where at least some of the key values get set to the current value of some
 > LaTeX parameter (one could argue that this is bad programming, but this
 > kind of thing is sometimes hard to avoid).

is it really hard to avoid or is it only the way we are used to write classes
(like using \baselineskip and later on changing it and not noticing that they
are different).

in some sense it means that you define sort of meta variables or rather "class
constants" that you set near the top and then reuse. There is something to
that as it (if done carefully) helps to structure your template instantiations
and give them some sort of extra flexibility.

on the other hand if one does that too much you get another hierachy into the
layout process which is difficult to understand.

but that doesn't really mean one shouldn't offer it.

frank

ATOM RSS1 RSS2