Janek Warchoł <janek.lilyp...@gmail.com> writes: > 2013/8/7 David Kastrup <d...@gnu.org> > >> Han-Wen Nienhuys <hanw...@gmail.com> writes: >> >> > On Sun, Aug 4, 2013 at 9:18 AM, David Kastrup <d...@gnu.org> wrote: >> >>>>>> I don't think that distributing ( and ) between standalone event and >> >>>>>> post-event respectively is a concept that will carry the day >> >>>>>> sufficiently to be given a chance at a comeback. It would make >> >>>>>> (c (d) e) >> >>>>>> visually confusing. While neither the current >> >>>>>> c( d)( e) >> >>>>>> nor the standalone event version >> >>>>>> (c )(d )e >> >>>>>> will win a price for prettiness, they both beat (c (d) e) in >> conveying >> >>>>>> meaning rather than looking pleasing. >> >>>> >> >>>> What about considering ( as a post-event and ) as a standalone event ? >> >>>> c( )d( )e is symmetric and very clear. >> > >> > c()d()e is a pain in the ass, and we got rid of it in the 1.8-2.0 >> > syntax change. It is a pain in the ass, because when copying music, >> > you have to remember to put some adornments (ie. the ')' ) before the >> > note, while most go after the note. >> >> Example? While I am apparently preparing the ground for historic >> reenactments, we'll want to convey some of the original horror, and I >> don't get it yet. >> > > Do i understand correctly that > http://code.google.com/p/lilypond/issues/detail?id=3487 would change slur > syntax from c( d)( e) to c()d()e ? > I have to say that i don't like c()d()e.
No, you don't understand correctly. It just makes possible redefining things like ( and ) so that you _could_ write a document in that style if you wanted to. I think it should be obvious from the issue description and review. I actually changed the regression test to something less scary, namely redefining ( and ) as \melisma and \melismaEnd (not possible previously because they behave like articulations to the user but aren't to LilyPond). -- David Kastrup _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
