[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: order of engravers

From: Carl Sorensen
Subject: Re: order of engravers
Date: Wed, 28 Apr 2010 08:58:29 -0600

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

> Kieren MacMillan <address@hidden> writes:
>> Hi Graham et al,
>>> Talking about
>>> 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
>>     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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]