Re: table rows in a galley

[Jeff Kingston]

> But when I make a galley inside the table, things I send to
> the galley don't have access to the scope of the table: for
> example, @Rowa is undefined or misspelt.

Even worse (if I understand what you are trying to do correctly),
every galley has a single column mark, and so you can't pass a
table row, which has several column marks, through a galley;
or rather, you can, but what comes out the other end has a
single column mark and will be treated as a single column.
Uwe already pointed this out, and he also wrote:

> I have a vague feeling that you are not splitting responsibilities
> between the generating program and lout quite right and that makes
> you write lout code that is more complex than necessary.

I agree with his comment.  If you are generating the Lout source with
a program then you probably don't need a layer of your own definitions
at all; just go ahead and generate the tables you need.

Definitions with parameters are much easier to work with than galleys,
and they are often the best way to separate format from content.  Make
a definition with one parameter for each distinct element of content,
and a body containing all the layout.  When the content is an arbitrary
number of table rows and columns, you have to do something to indicate
within the content where the column and row breaks are.  Here is an
example using / and | (see the Expert's Guide) rather than @Tbl:

    def @Seasons
        right body
    {
        Winter | Spring | Summer | Autumn
        /
        body
    }

and then you can write

    @Seasons
    {
        Skiing | Floods | Droughts | More droughts
        /
        Cold | Wet | Hot | Less hot
    }

which would make a table with four columns and three rows.  The
value of "body" can have any number of column and row marks, and
these will be merged correctly with column and row marks at the
point where "body" is used inside the definition of @Seasons.
Using Lout primitives avoids the scoping problems with @Tbl.

Jeff