Re: order of function arguments

[David Kastrup]

Janek Warchoł <address@hidden> writes:

> ooops, seems like i'd fallen behind.  The last thing i remembered
> about \tweak syntax was this:
> http://code.google.com/p/lilypond/issues/detail?id=2540
> Back then the syntax was
> \tweak optional-grobname property value music
> And i liked it.  Somehow i didn't realize that this was changed into
> \tweak property value grob-or-music
> ...
>
> 2013/4/22 David Kastrup <address@hidden>:
>> This was issue 2929
>> <URL:http://code.google.com/p/lilypond/issues/detail?id=2929> and I
>> answered your question in comment #7 in October.  The only alternative
>> is to provide _only_ overrides and force the user to use \single if he
>> needs a tweak.  But this requires the user to know the grob name for the
>> override, defeating the simplicity of \tweak.
>
> ...yeah, that's it.  I didn't realize/understand it back then.
>
> Btw, issue 2540 made it possible to write
>
> \version "2.17.3"
> { < \tweak Accidental #'color #red cis' fis'' > }
>
> which colored the sharp of the cis.  Is it possible to achieve the
> same goal with newer versions?  I've tried some combinations with
> 2.17.13 but they failed.

If you don't want to read the manual, you can use convert-ly.

>> Janek Warchoł <address@hidden> writes:
>>> It's not doing us good when user interfaces for different
>>> functions don't have a common specification wrt/ argument
>>> order.
>>
>> Where do we have different argument order to existing functions?
>
> Uh, what about
> \override grob property = value
> \tweak property value grob-or-music
> ?
> "grob" appears in different places - sometimes before a property name
> and sometimes after it.  This is confusing.

Then don't use \tweak property value grob.  Simple as that.  It's just
alternative syntax for \once\override grob.property = value which is
more interesting when you have an alias like \hide or \omit.

>> I don't see a better solution here.  Obviously, or I would not have
>> converged to the behavior implemented in October.  Unless you can
>> come up with anything that has not already been considered and/or
>> discussed, this is not going to lead anywhere.
>
> well, i have one idea that i think wasn't quite discussed.  However, i
> suppose i have to learn more about parser and related things to have a
> meaningful discussion, so i suppose this has to wait.

That sounds like you are planning for something that can't be made to
work with the current parser and music functions.  Which probably means
that it is going to make things nicer at the price of making things
considerably more complex.  Giving me a good hunch how the meaningful
discussion is going to go.

We are living in the best of all conceivable worlds.

-- 
David Kastrup