Kieren MacMillan <[email protected]> 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. -- David Kastrup _______________________________________________ lilypond-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/lilypond-devel
