"m...@apollinemike.com" <m...@apollinemike.com> 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 _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
