On Thu, Sep 6, 2012 at 12:15 AM, Reinhold Kainhofer <[email protected]> wrote: > [1] Note, however, that ANY change, even a very small, subtle change, is a > really grave argument for a music publisher against using lilypond. > I wrote a huge piece (~95 pages full score, 23 orchestra instruments, choir, > etc) a few years ago. I didn't count the hours it took me last month to > bring it up to date with the latest lilypond version (I had to visually > compare the whole full score and all instruments to make sure that nothing > had been lost). > At that time, I really, really, really cursed lilypond and its frequent > syntax changes.
:( I think that's Graham's point: syntax changes are bad, so if we have to make them (and apparently we still have to), let's do it once and for all. Or at most 1-2 times per decade. In order for this to make sense, we must be really confident in the syntax we are going to label "stable". That's why i think we all need a lot of discussions to get a better understanding of both user needs and problems in parser (ambiguities etc). In my opinion Lily syntax isn't expressive enough, which means that sooner or later we'll have to make some changes, which means that we should make them now. Example: hairpins. There is no convenient way of specifying hairpins that don't align with the notes (you have to use spacer rests, which is bad for a number of reasons). We need to have a convenient way. Adding this will be a syntax change, so let's do it now instead of later. Another example: vertical hairpins attached to arpeggios (Elaine Gould shows them). I don't think we have a simple way of extending our syntax to express them - some basic design principles would have to be changed a bit, i suppose. So let's change them now. In fact, i really do think that lack of expressiveness is one of the big reasons why we have syntax changes. When something is impossible to express in "native Lily" (like the hairpins attached to arpeggios), people invent worarounds. Workarounds are more likely to stop working, and each workaround will be different. That's why i think we need to design syntax that's easy to extend (as well as unambiguous). cheers, Janek _______________________________________________ bug-lilypond mailing list [email protected] https://lists.gnu.org/mailman/listinfo/bug-lilypond
