Re: 2.16 release candidate 3 imminent

[address@hidden]

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, see if was 
an event chord or a note event, and act on it accordingly.  So, for example (in 
pseudocode):

#(define (bar music)
  (do-some-stuff-to music))

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

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.

Cheers,
MS