Re: order of engravers

[Carl Sorensen]

On 4/28/10 6:41 AM, "David Kastrup" <address@hidden> wrote:

> Kieren MacMillan <address@hidden> writes:
> 
>> Hi Graham et al,
>> 
>>> Talking about
>>> http://code.google.com/p/lilypond/issues/detail?id=673
>>> problem with order of \consists
>>> 
>>> 1)  Add a sentence about default_bar_line_engraver and
>>> timing_translator  (or whatever Werner was talking about on 673).  I
>>> know we've already said "there order may matter; here's one example,
>>> but there may be others", but we might as well list this case since it
>>> came up.
>>> 
>>> 2)  Do some trawling through the IR and/or code (as per Han-Wen's
>>> comment 5 in the issue)  and try to discover all dependency chains of
>>> engravers, then list all those in Notation.  If you go to this much
>>> effort, we might as well make a separate section (well,
>>> unnumberedsubsubsec) in the docs for these dependency chains.
>> 
>> From the "header" comments in IR:
>> 
>>     Auto_beam_engraver requires Stem_engraver
>>     Bar_number_engraver requires Staff_collecting_engraver
>>     Default_bar_line_engraver should be at the same level as
>> Timing_translator
>>     Mark_engraver should stay with Staff_collecting_engraver
>>     Metronome_mark_engraver requires Staff_collecting_engraver
>> 
>> From comments in engraver-init.ly:
>> 
>>     Bar_engraver must be first so default bars aren't overwritten with empty
>> ones.
> 
> And so on.  One could automate documentation generation by making it
> possible to specify order/dependencies when defining engravers.
> 
> And if each engraver specifies what engravers it is relying on in a
> machine-readable manner (or the respective order in which it wants to be
> applied), then Lilypond can actually do the required sorting and figure
> out a proper order at runtime.

Patches thoughtfully considered.

Carl