lilypond-devel
[Top][All Lists]
Advanced

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

Re: 2.16 release candidate 3 imminent


From: David Kastrup
Subject: Re: 2.16 release candidate 3 imminent
Date: Sun, 22 Jan 2012 11:07:48 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.92 (gnu/linux)

David Kastrup <address@hidden> writes:

> David Kastrup <address@hidden> writes:
>
>> If I write
>> myC =
>> #(define-music-function (parser location) () #{ c #})
>> then I can't currently write
>> <\myC>4 or similar.  It would just not work.  And there is no way to
>> define this function, #{ #} or not, in a manner that could work both in
>> chords as well as outside (without a Rhythmic Event iterator).
>>
>>> This is the part that I have the most trouble imagining, not because I
>>> don't trust you, but because I don't follow the code well enough to
>>> know how it would result in this.  I'd like to see regtests in one of
>>> these commits that uses two or three simple functions in the form \foo
>>> c and <\foo c> that show this distinction.
>>
>> Is the above simple enough?
>
> If it isn't, try
>
> myC=c
>
> No need to even stoop to music functions.  In this case, <\myC> will not
> work without the change in parsing.

Actually, neither will it with the change.  But it will be a one-liner
to make it work when it was impossible previously.  I'll do that
one-liner presently.

-- 
David Kastrup




reply via email to

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