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.
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
