On 4/28/10 6:41 AM, "David Kastrup" <d...@gnu.org> wrote:
> Kieren MacMillan <kieren_macmil...@sympatico.ca> 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
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
