On Jan 21, 2012, at 6:14 PM, Keith OHara wrote: > Carl Sorensen <c_sorensen <at> byu.edu> writes: > >> On 1/21/12 9:45 AM, "Graham Percival" <graham <at> percival-music.ca> wrote: >>> On Sat, Jan 21, 2012 at 05:27:00PM +0100, David Kastrup wrote: >>>> I would very much prefer the work on Issue 2240 (aka 2070) to make it >>>> into 2.16. It is a significant API change >>> >>> IMO, significant API changes should not happen right before a >>> release. >> >> We wanted stable versions to >> have a significant lifetime so things like LilyPondTool and Frescobaldi >> didn't need to always keep changing. >> > > The implication is that issue 2240 changes the interface (but not the > input syntax because there is no convert-ly rule) in a way enables > improvements user code (presumably Scheme) that we will want so badly > that we cannot wait for 2.18. > > Does anybody know what 2240 improves ? >
I was asking myself a similar question lately now that I've gotten deeper into the non-parser-related aspects of 2240. After playing around with iterators and such, I'm convinced that all the articulation stuff can be written to be slicker independent of any changes to the parser. Meaning that, without any changes to the representation of event-chords, we could get rid of the script engraver and fingering engraver and just keep the new fingering engraver, doing all necessary massaging at the iterator level. My question is this: what is the basic advantage of having rhythmic events not wrapped in event chords? I understand that it can be used to wedge a distinction between <c> and c, but how is this distinction useful? Especially given the perspective David addressed earlier that part of LilyPond's code base getting better will be it getting more uniform and boring, how is this move away from uniformity (meaning creating two channels for of handling rhythmic events) beneficial? I think the question boils down to: is there an inherent difference between <c> and c and, if so, what is it and why is it meaningful? Cheers, MS _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel