Re: Make arguments like Context.GrobName accessible as symbol lists (issue 6635050)

[dak]

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/