Re: untangling the remaining regressions

[David Kastrup]

Keith OHara <address@hidden> writes:

> David Kastrup <dak <at> gnu.org> writes:
>
>> "Keith OHara" <k-ohara5a5a <at> oco.net> writes:
>> 
>> > 'cross-staff' marks grobs whose positioning (relative to their parent)
>> > depends on the spacing of staves on the page.  These grobs have to be
>> > positioned last, after all grobs moving with their parent Staff are
>> > positioned relative to him, and staves are spaced.  There is not an
>> > overarching mechanism to enforce this timing.
>> 
>> Given the complexity of getting these kind of things right manually, we
>> most definitely _want_ an "overarching mechanism" in place here.
>
> It is not yet completely clear to me what the mechanism needs to do.

When in doubt, everything.  I should have been more explicit here in my
reply.  You wrote "there is not an overarching mechanism to enforce this
timing", but we don't really want an enforcement police that tells the
user "you're wrong, try again".

The user/programmer should specify the relations he wants to hold, and
then it's the computer's job to figure out how to do that.

> For most cases, we know

See, that's what I mean.  When we are talking about a multitude of
cases, it's the computer's job to know.  When I'm telling the bakery I
need 100 loaves of bread at 10:00am, then I don't expect that they pull
out the schedules of the ovens and ask me to rearrange the baking
patterns for them.  What I expect is "can do" or "won't do".

> that vertical-position properties like Y-extent and *-skylines on a
> cross-staff grob should not be finalized before staff-spacing is done.
> Maybe grob_property() can check, before calling a callback function,
> whether the grob in question is marked cross-staff.  and if so check
> whether staff-spacing is done. If the grob is cross-staff but
> staff-spacing is not done, only a 'pure' version of the callback
> function can be used, and if none is available we can only return
> 'nil'.
>
> It is not clear whether grouping objects that contain some cross-staff
> grobs should be marked 'cross-staff'.

But the average programmer extending LilyPond should not need to know.
It's an implementation detail.  I don't have a plan how to get to the
situation where the computer does that job.  But that's where we have to
end up eventually.

The advanced user can already do quite a few things by juggling
engravers (and that entails making a lot of connections and
disconnections behind the scenes automatically) and their relation to
contexts.  We need to arrive at a state where one can juggle on a
similarly abstracted level with relations between grob placements and
have LilyPond figure out mechanically how to make that work.

-- 
David Kastrup