lilypond-devel
[Top][All Lists]
Advanced

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

Re: order of function arguments


From: Janek Warchoł
Subject: Re: order of function arguments
Date: Tue, 23 Apr 2013 17:37:02 +0200

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.

> 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.
I know that i don't know what to do about this, but i also know that i
don't quite like current situation.

>> (as you know, my ultimate goal is merging as many modifying
>> commands, e.g. merging \set and \override - but i'm not trying
>> to suggest any solutions, because i have no expertise in this
>> area, just some expectations).
>
> 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.

Janek



reply via email to

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