http://codereview.appspot.com/6635050/diff/15002/Documentation/notation/changing-defaults.itely File Documentation/notation/changing-defaults.itely (right):
http://codereview.appspot.com/6635050/diff/15002/Documentation/notation/changing-defaults.itely#newcode4202 Documentation/notation/changing-defaults.itely:4202: \tweak NoteHead.stencil #ly:text-interface::print On 2012/10/13 05:16:00, Keith wrote:
The dotted form is very nice.
This way we always have two arguments, each of which can be expanded
to a dotted
form to clarify where to find the thing we want LilyPond to change.
This
more-regular syntax is easier to remember than optional arguments.
{ \override Script X-offset = #-0.5 d'-> d'-\tweak X-offset #-0.5 -> \override Staff.Stem X-offset = #0.7 << g' \\ b >> \tweak Stem.X-offset #0.25 g' }
The mailing list discussion pointed out the inconsistency between the use of dots between tweaks and overrides. If tweaking of nested properties is implemented at some point of time, recognizing the specification of an optional context when at the same time optional trailing path components might be available is not really feasible. Several proposals for changing this have been put forward. Have to think about this. http://codereview.appspot.com/6635050/diff/15002/lily/footnote-engraver.cc File lily/footnote-engraver.cc (left): http://codereview.appspot.com/6635050/diff/15002/lily/footnote-engraver.cc#oldcode49 lily/footnote-engraver.cc:49: IMPLEMENT_TRANSLATOR_LISTENER (Footnote_engraver, footnote); On 2012/10/13 05:16:00, Keith wrote:
I don't see now the new syntax avoids the need for a listener -- is
this
clean-up of unused code ?
The new syntax allows a grob specification _with_ context, allowing to turn a "time-based" footnote into a proper override instead of an event. Since the tweak-like interpretation of the "footnote-music" field was already in place previously, this works just as well. The disadvantage is that you have to specify the context in case of things like Staff.TimeSignature, just like you would have to do with any override. The advantage is that this is predictably similar to other operations and does not require you to juggle the Footnote_engraver between different contexts in order to have it do its job in difficult circumstances. So this change of operation is not forced by the new syntax, but rather facilitated. Since there is no longer anything generating footnote music events for any purpose except sticking it into the footnote-music property of grobs, using a Music data structure at all for storing the footnote data is pretty arbitrary. It might be subject to later cleanup, but I wanted to keep the changes reasonably confined. This is probably something that is easier to examine in the scope of its change as a commit in the dev/syntax branch http://codereview.appspot.com/6635050/ _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel