James <pkx1...@gmail.com> writes: > On 4 October 2012 09:28, David Kastrup <d...@gnu.org> wrote: >> > .. > >> >> Using the symbol list form would have the advantage that >> >> \override TextSpanner #'(bound-details left text) = "rit." >> >> could equivalently be expressed as >> >> \override TextSpanner bound-details.left.text = "rit." >> >> and >> >> \override Bottom.TextSpanner #'(bound-details left text) = "rit." >> >> as >> >> \override Bottom.TextSpanner bound-details.left.text = "rit." >> >> or even >> >> \override #'(Bottom TextSpanner) bound-details.left.text = "rit." > > I know I have cut out most of the initial email, this is deliberate > because I just want to point out, that at least from a 'normal' user > point of view none of them are particularly better than the other.
I did not want to imply a qualitative judgment here. I was just pointing out how the work on an an implementation choice allowing to specify Bottom.TextSpanner as a music function argument led to a set of equivalences for parts of existing constructs in a somewhat natural manner. > Personally I like using braces or parenthesis to separate out these > different parts to these overrides. It is a pain (for me) to recall if > I need to use '#'' or not but that is no different than having to > remember if I use dots or spaces. > > If all you are saying is it doesn't matter which one a user picks, > they will work, then fine, but sometimes too much choice or rather, > too much opportunity to 'type it wrong' may lead to frustration or > incomprehensibility if we report a technically accurate but > hard-to-understand error message. > > Also, won't anyone think of the IDEs! It is not just the IDEs. Obviously when one departs from "established" usage, the pattern matching facilities of convert-ly and similar get strained as well. In general, extensibility is bad news for all those. I think that in the long run, LilyPond will have to acquire MusicXML as an additional rigid computer-readable/writeable native input language or input layer to better facilitate using it as a typesetter for systems without native understanding of LilyPond, similar to how PDF is a rigid file format in the universe of PostScript interpreters. -- David Kastrup _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel