Re: various problems

[Valeriy E. Ushakov]

On Tue, Jan 20, 1998 at 09:46:53AM +1000, Jeff Kingston wrote:

> There seems to be an air of crisis in the mail which has prompted this
> reply.  I don't think there is a crisis.

Neither do I.  I (and Pieter, as far as I understand) was talking
about a different matter.  It's not that there's a crisis with Lout
per se, rather there're objective difficulties people experience when
they try to utilize Lout in their projects and this difficulties stem
from the fact that learning Lout (as it is) is difficult.  It's about
learning the language, not about the language.


> Difficulty in understanding expert's guide
> ------------------------------------------
> 
> It would certainly benefit from a rewrite, but my time is taken up
> completely by maintaining the Lout implementation.  Any volunteers?

Jeff, my English is not up to the task of expressing most heartful
thanks and appreciation that we, Lout users, feel.

The best thing we, as a Lout community, can do to make Lout more
successful (and we want it to be more widespread, more available, used
in more projects, aren't we?) is to allow Jeff to concentrate on the
implemenation and take the task of spreading the Lout gospel.

If Lout is better documented (I mean expert's guide and the like), it
will be easier for people to master and use in their projects.  I
think that was one of important points in Pieter's posting and I agree
with him.


> Also, in fairness the difficulty of understanding Lout galleys
> should be compared with the difficulty of understanding troff
> diversions and traps, and TeX floating insertions and output
> routines (or whatever they're called).

Yes, but galleys are used more heavily so every effort should be made
to document them and their usage in great detail.


>                                         A great deal of useful
> code can be written without using galleys and cross references.

But a great deal of advanced things can't be implemented without them.
When people consider Lout as a target for their projects, they will
most likely need that advanced stuff.


> Organization of standard packages
> ---------------------------------
> 
> The essential point seems to be that the standard packages contain a lot
> of locked-away expertise which requires a great deal of expert knowledge
> to understand and modify.

Reading quality code is one of the most effective ways to learn
something.  If someone is to write Lout code of the level of
complexity comparable to standard Lout packages one will need the
level of expertise that is sufficient to understand the standard
packages.  And most likely reading and understanding the code for
standard packages will be the major source of that expertise.


> I'd love to hear some suggestions in this area, or pointers to systems
> that are much easier to configure than Lout is.  I feel myself that some
> kind of even more modular design would be good, but I don't know what.

One thing that may be worth doing is separating page layout from
displays, lists and other higher-level stuff.  Then people can reuse
page code easier.  May be it's worth to take a look at the
specification of page-sequence and column-set-sequence DSSSL flow
object classess, it *might* suggest some ideas on what set of features
the page layout code might provide.


> The specific example of displays in a box could be handled by adding a
> setup file parameter similar to @TitleFormat (is it?), so that one could
> write
> 
>     @DisplayFormat { @Box @Body }
> 
> in the setup file.  I think Lout would be improved by dramatically
> increasing the number of setup file options of this kind.  Right now it
> is easy to define a @BoxedDisplay macro.

I guess that here you refer to the follwing discussion:

[uwe: I have abridged this quote a bit]
pieter> The galleys for the 'standard' lout are definately *inside*
pieter> the 'packages' .....  In order to change these galleys one has
pieter> to dive inside these files and replace the interesting
pieter> @whatever { galley } into @whatever { def @Enclose ... galley }.

I then replied with an example that demonstrates that standard
`extend' clause can be used to inject the @Enclose into the galley:

    extend @DocumentLayout
    def @EncloseDisplay # -- the name doesn't really matter
    {                   #    we just need to sneak into the @DocumentLayout
      extend @Disp      # -- and inject our own @Enclose into the @Disp
      def @Enclose
        right x
      { @Box x }
    }

I used @Disp just because it was easier for me to test if this code
works.  It's meant to` demonstrate what Lout scoping rules can do.


SY, Uwe
-- 
address@hidden                         |       Zu Grunde kommen
http://www.ptc.spbu.ru/~uwe/            |       Ist zu Grunde gehen