Re: Discuss signature for new function \annotate

[David Kastrup]

Urs Liska <address@hidden> writes:

> Am 06.06.2013 12:22, schrieb David Kastrup:
>
>> If your first argument is something like Script, you might want to make
>> it of type symbol? instead.  I actually have a syntax sanitizing patch
>> in limbo where unquoted words are not accepted as strings.  It is not
>> going to make it into 2.18, but I don't promise I won't push it at some
>> later point of time.
> What type is the 'grob' argument of \shape?

<URL:http://lilypond.org/doc/v2.17/Documentation/notation/available-music-functions#index-shape-1>


 shape [music] - offsets (list) item (symbol list or music)

    Offset control-points of item by offsets. The argument is a list of
    number pairs or list of such lists. Each element of a pair
    represents an offset to one of the coordinates of a
    control-point. If item is a string, the result is \once\override for
    the specified grob type. If item is a music expression, the result
    is the same music expression with an appropriate tweak applied.

The documentation string states "If item is a string", but that's
actually inaccurate and would warrant fixing.

> And: with \shape the order of arguments was reversed for syntactical
> reasons (that I didn't really understand).

When commands with arguments are used as tweaks on a music expression,
multiple such commands combine quite awfully when the music expression
is not consistently the last argument.

> I would also like to \annotate e.g. individual notes from chords
> etc. So what would I have to take care of?

Putting an "item" of type symbol-list-or-music? last seems like a
reasonably good idea.

>> It is probably worth considering to make properties of type context-mod?
>> (potentially optional), then you can write the argument as
>>
>> \with {
>>     voice = "vc1"
>>     source = "Ms. 2"
>>     author = "Urs Liska"
>>     date = "2013-06-06"
>> }
> That looks very good. How would the values then be accessed? Are they
> simple variables inside the function? Or does that also create an
> alist internally

Lists.

address@hidden:/usr/local/tmp/lilypond$ lilypond scheme-sandbox
GNU LilyPond 2.17.20
Processing `/usr/local/share/lilypond/2.17.20/ly/scheme-sandbox.ly'
Parsing...
guile> (ly:get-context-mods #{ \with { voice = "vc1" source = "Ms. 2" } #})
((assign voice "vc1") (assign source "Ms. 2"))
guile> 

>> Of course, you might get unsets and overrides and reverts slipped in
>> which you would want to weed out again, but list? is also prone to
>> permitting a lot that you don't want to see.
> Sure. I'd have to iterate over the alist and ignore all keys I can't
> handle. But how would that be with a context-mod?

guile> (ly:get-context-mods #{ \with { \unset voice \override Beam.stencil = 
##f} #})
((unset voice) (push Beam #f stencil))

-- 
David Kastrup