Re: 2.16 release candidate 3 imminent

[David Kastrup]

"address@hidden" <address@hidden> writes:

> After reading through this e-mail, I'm ok with the patch with one
> caveat about regtests (see below).
>
> On Jan 22, 2012, at 9:08 AM, David Kastrup wrote:
>
>> Music expressions _represent_ the input, as opposed to stream events
>> which represent the typesetting task.
>> 
>
> If this is truly the distinction, then I understand the need for the
> change.  I didn't realize that music expressions needed to be
> one-to-one and onto representations of the input.
>
>> And you currently _can't_, I repeat _can't_ write a music function
>> (unless it gets a music argument created by the parser instead of
>> just passed in from elsewhere) that can work like the input "c"
>> inside of a chord as well as outside.  Because outside, you need to
>> produce <c>, and inside, you need to produce c.  But without a music
>> argument?  No.  Writing a music function called as \semitonesabovec
>> #5 (or something like that) that will work both inside as well as
>> outside of chords is just _impossible_ right now.  It will be trivial
>> afterwards.
>> 
>
> 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.
>
> I thought that any music function could look through its argument,

Please reread the above paragraph, in particular where I say "without a
music argument".

> see if was an event chord or a note event, and act on it accordingly.

Without an argument you can look at, you can't choose your action
accordingly.

> #(define-music-function (parser location music)
>   (if (eqv? (ly:music-property music 'name) 'EventChord)
>       (bar (car (ly:music-property music 'elements)))
>       (bar music)))

_Without_ a music argument.

> The idea that a music function would be unmakable before this commit
> and makable after is, in my mind, the most solid argument for making
> this change.  Like I say above, I'd need to see this in a regtest.

You can make a music function that will either work in chord context, or
in music list context.  And it can ask its music argument which of the
two it is.  I think \parenthesize does that.  But that only works if
there _is_ a music argument.

It is possible that the operation of the music function parenthesize can
be simplified in future, but it may require special behavior on
EventChord anyway.

-- 
David Kastrup