Re: Punctuation spacing

[Jeff Kingston]

> I don't see how this is different from address@hidden', address@hidden',
> address@hidden', etc. ... In Lout, these things are implemented as part
> of the style of an object which is itself inherited from the
> enclosing object.  Wouldn't it be possible to treat punctuation
> spacing similarly?

Yes, it would mean that if you have text inside an equation you
would need to enclose it in @Language (or @PunctuationSpacing if
a variable separate from the language style variable is used), to
get the outer style back.  This is one of the two things I don't
like about this approach; even if it doesn't occur very often, it
introduces interactions between otherwise independent packages, a
sign of bad design.  The other thing is the hard-wiring of language
specific rules into C code.  I'm still guessing that an include
file of definitions would be better; can we see what definitions
you actually need, and go over the places where they cause trouble?

                              ---

To go further into this I am going to have to explain the Nonpareil
solution to this problem.  In Nonpareil, each kind of object
(equation, table, ordinary text etc.) will be free to contribute its
own variables to the current style (called environment in Nonpareil
by analogy with Unix environments).  If an A lies within a B which
lies within an A, B will pass A's environment variables through
unharmed; indeed it will often not even know that they exist.  So
you get context-sensitivity yet maintain independence between the
different types of objects - the best of both worlds.

But in Lout there is unfortunately no such separation; everything
is text, and so everything accesses the style variables that affect
text and might need to change those variables, making for unwelcome
interactions.  For example, @Eq changes the inter-word spacing style
variable, hence text within equations has to be enclosed in @Space
(or @Font, which also sets that variable).

Jeff