Pavel Roskin <pro...@gnu.org> writes: > Quoting Graham Percival <gra...@percival-music.ca>: > >> On Sun, May 06, 2012 at 08:58:11AM +0100, Trevor Daniels wrote: >>> >>> David Kastrup wrote Sunday, May 06, 2012 2:57 AM >>> >>> >In fact, isn't <> generally prettier than s1*0? Should we be using it >>> >in code and documentation rather than s1*0? >>> >>> Definitely prettier, but maybe not so transparent as s1*0. >> >> +1 >> >> What about defining a >> null >> or >> n >> "note name"? Then we could write >> c4 n\footnote > > My preference is "z". There are fewer words that start with "z" than > with "n" and it's easy to remember "z" as shorthand for "zero". > > Reusing symbols like "<" and ">" for new meanings would turn Lilypond > sources into something like Perl.
It is not a reuse. It already works fine. q does not behave consistently when used around it, but that is basically a one-line change and a problem of q. \displayLilyMusic does not show it right, but since it is valid input, that is more the problem of \displayLilyMusic rather than anything else. I am just fixing that. There may be a case for making << { c4 d } { <>-. <>-- } >> produce the same output/stream-events as { c4-. d-- }: that would be a decent expectation. However, chords < > do not carry duration information by themselves but only by virtue of propagating it to their elements, of which there are none in < >. I am not fond of the behavior of <>4 (the duration, short of setting the default duration in the parser, will get ignored) and will readily admit that. However, <> is rather idiomatic and thus one will less likely fancy the idea of writing <>4 than one would writing z4, and the inconsistency in behavior when writing the former strikes me as less unsavory than of the latter: < ... > works as a duration override. You can write sample = c2 < \sample >4 and the result will be a quarter note. That a content-less chord does not catch durations is somewhat understandable. For something called z, this is a bit less obvious. -- David Kastrup _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel