Get along with use of grob-property instead of grob-property-path in overrides

Get along with use of grob-property instead of grob-property-path in overrides

LilyPond uses a willy-nilly mixture of grob-property and
grob-property-path when generating overrides programmatically (the
parser only uses grob-property-path).  Several override-reinterpreting
commands and functionalities were not prepared to deal with this.

[janek, 2012-09-26 06:14:04]

Do i understand correctly that grob-property-path is just a list of properties,
like '('thickness 'gap 'color)?  If so, i find the name misleading.

Anyway, i don't feel competent to give an "LGTM" to a Scheme patch i don't
understand - but i had certainly not noticed anything wrong.

http://codereview.appspot.com/6544060/diff/1/ly/music-functions-init.ly
File ly/music-functions-init.ly (right):

http://codereview.appspot.com/6544060/diff/1/ly/music-functions-init.ly#newco...
ly/music-functions-init.ly:1073: (ly:music-property m 'grob-property-path)))))
Scheme syntax pwned me again, but i suppose this just uses either grob-property
or grob-property-path depending on need.

[dak, 2012-09-26 07:10:57]

On 2012/09/26 06:14:04, janek wrote:
> Do i understand correctly that grob-property-path is just a list of
properties,
> like '('thickness 'gap 'color)?

Apart from overquoting (when quoting a list, its members are already
quoted), yes.

> If so, i find the name misleading.

That terminology is employed in a number of places in the grammar and
code, and this patch does not invent any property but just deals
better with existing definitions and usage.

> Anyway, i don't feel competent to give an "LGTM" to a Scheme patch i don't
> understand - but i had certainly not noticed anything wrong.
> 
> http://codereview.appspot.com/6544060/diff/1/ly/music-functions-init.ly
> File ly/music-functions-init.ly (right):
> 
>
http://codereview.appspot.com/6544060/diff/1/ly/music-functions-init.ly#newco...
> ly/music-functions-init.ly:1073: (ly:music-property m 'grob-property-path)))))
> Scheme syntax pwned me again, but i suppose this just uses either
grob-property
> or grob-property-path depending on need.

Not "on need".  If the property grob-property is defined, it calls
"list" on it to create a one-element list (which this code as well as
similar code elsewhere is expecting), otherwise it takes the property
grob-property-path as the source for that list.

This is the same way that lily/property-iterator.cc does it.  I
consider this a rather awkward compatibility crutch (grob-property is
not used by any manually written overwrites, just by legacy Scheme
code), but it was not the scope of this patch to change that.

[janek, 2012-09-26 07:27:57]

On Wed, Sep 26, 2012 at 9:10 AM,  <dak@gnu.org> wrote:
> On 2012/09/26 06:14:04, janek wrote:
>> i find the name misleading.
>
> That terminology is employed in a number of places in the grammar and
> code, and this patch does not invent any property but just deals
> better with existing definitions and usage.

Sure, i didn't mean to blame you.

> Not "on need".  If the property grob-property is defined, it calls
> "list" on it to create a one-element list (which this code as well as
> similar code elsewhere is expecting), otherwise it takes the property
> grob-property-path as the source for that list.

Ah!  thanks for explanation.
Janek