Re: Project - Eliminating grob parents and outside-staff-priority

[Han-Wen Nienhuys]

On Wed, Sep 26, 2012 at 9:17 PM, address@hidden
<address@hidden> wrote:

> Another way to think of this is that, in general, we'd try to eliminate
> grobs like NoteColumn, ScriptColumn, DynamicLineSpanner, etc that only do
> traffic-coppery.  Or, inversely, we'd say that positioning only happens via
> traffic-cop grobs and no grob has the right to position itself.  But it
> seems like we need to pick one.

The reason for trafic-coppery is that for many positioning schemes,
there is no inherent order that can determine how two objects of the
same type (and hence, with the same set of callbacks) should be
typeset.

A typical example of this is NoteCollision of N NoteColumns. The
NoteColumns have to all move in a coordinated way, and the easiest way
is to have a function (with local variables) that determines what has
to happen. You might get around it, by having a bunch of properties
instead, but you'd still have to store those somewhere, ie in the
NoteCollision grob.

> Agreed, but this is just one instance of translate_axis, which is just one
> example of a side-effect in lilypond. Is your eventual goal to remove them
> all?
>
>
> Yes - that'd be great.  That'll make explicit dependencies a lot easier to
> handle - everything can be calculated in terms of callbacks.

I'm all for removing side effects, but you can pursue that separately
without trying to rewrite the backend.


> To keep the main thing the main thing, the goal is to be able to wipe
> certain caches, restore the original callbacks, and know that all grobs
> properties that depended on the restored property will also be recalculated.
> My idea is an idea for simplifying LilyPond so that this work is easier, but
> there is no point in doing that if it won't help reach that goal.  I'm open
> to any and all suggestions.

Have you thought this through?

In order to do cache invalidation, you will have to construct the
reverse graph. If A.x depends on B.y, now A points to B. For proper
cache invalidation, if B.y changes, then A.x becomes invalid. This
means that A has to store a back-reference to B. Hence all pointers
have to be stored both ways (including inverting 1-N relations into
N-1 relations), and the both-way links have to be rewritten correctly
during line breaking.

-- 
Han-Wen Nienhuys - address@hidden - http://www.xs4all.nl/~hanwen