Re: order of engravers

[Kieren MacMillan]

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.
    New_fingering_engraver must come before Script_column_engraver

Based on Werner's specific problem:

    Default_bar_line_engraver must come before Timing_translator

This last one is easy to determine by looking at [only] the IR: under 
"defaultBarType" it says "This variable is read by [...] Timing translator”. 
Unfortunately, that's the only example of the phrase "this variable" that I 
could find in the IR. So if I want to determine other dependencies more 
specifically, I need to dig deeper and more manually [pun partially intended].

Han-Wen's comment (in the tracker) suggests I should look for 
Context_def::instantiate. I'm assuming that's in the C++ code?

> 4)  Pester some code people into adding "this context/engraver depends
> on context/engravers foo band bar" into the code documentation, such
> that this info will automatically get into the IR.  Oh, maybe modify
> the IR-generation functions to read this new info.
[...]
> 4 could be a fantastic project for a Frog that was thinking about improving 
> the IR...

If someone could guide me gently into that good night, I might be up to it.

Cheers,
Kieren.