>> 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.
I think that Reinhold is a bit unfair due to his frustration: He has
*certainly* used unstable development versions so that he can use his
own code improvements. It *must* be allowed by developers to change
the syntax while development still happens.
His very point is that deprecated syntax must either cause a warning
or an error *by running LilyPond itself*. I fully second that, and it
would be a valuable task to check that for the transition from version
2.14 to 2.16.
> 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.
IMHO the `convenient way' is to define a macro; I don't see a need for
a syntax change, since you always need rhythmical arguments to specify
the start and end.
> Another example: vertical hairpins attached to arpeggios (Elaine
> Gould shows them).
Interesting. I've never seen that before, I believe. Can you give a
link to an image?
> 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.
As far as I can see, what you want is not syntax changes. You simply
want new, additional commands. Or rather, an improved set of standard
macros which come with LilyPond.
Werner
_______________________________________________
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
