d...@gnu.org: Tuesday, October 09, 2012 9:38 AM
> Here is the rub: what we are currently talking about is a choice between > several convert-ly rules that all lead to valid programs after this > change. > > Whether you write > \override TextSpanner #'(bound-details left stencil-align-dir-y) = #-2 > or > \override Bottom.TextSpanner #'(bound-details left stencil-align-dir-y) > = #-2 > or > \override #'(Bottom TextSpanner) bound-details.left.stencil-align-dir-y > = #-2 and presumably even \override Voice.TextSpanner bound-details.left.stencil-align-dir-y = #-2 (which I prefer) > it is now all the same to LilyPond. > > Now it is nice to have found underlying principles making it possible to > obliterate fine distinctions and remove the necessity of using Scheme > for specifying a grob property path to modify, with mostly cosmetic > backward compatibility consequences. > > But since LilyPond is now able to _read_ a lot of different phrasings of > the same material, the question is how we want to be _writing_ this > material. Indeed. We need to define a canonical form for the bulk of the manuals, although we should explain the flexibility and available variants once. > I'll likely go for the quoteless \accidentalStyle form generally here. Good. > I think I'll prepare a radical convert-ly-only patch on top of this > patch series that demonstrates what "now valid" syntax we _could_ be > using/advertising as input if we wanted to. It's only right and just that you get first go at suggesting a canonical form, and a patch would be a good way of expressing your preference. (Regexp tutorial, anyone? Although we can always apply the patch and run it on the manuals.) > We can get rid of a _lot_ of #' style thingies with this patch series. The more the better. >> Let's get all the syntax changes incorporated in 2.17, >> then we can agree an immutable set ready for release 3. > > "Immutable" as "we guarantee we will be able to process this" rather > than "we guarantee we will write our scores to have input looking like > that"? I meant the former; the latter would be just an aspiration. As with the documentation, this will need an agreement on the canonical form. Trevor _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
