Keith OHara <k-ohara5...@oco.net> writes:
> Trevor Daniels <t.daniels <at> treda.co.uk> writes:
>
>> My point really is that <> exists now, so there ought to
>> be a short note in the section where chords are introduced
>> to say that an empty chord takes no time, whatever the
>> current duration happens to be.
>
> I agree with Trevor. And with David in liking <>
>
> s1*0 is useful for markup at the beginning of a
> multimeasure rest, quote, or cue, or at the end of a music
> as in "D.S.alCoda". In these cases, the next note needs
> an explicit duration anyway.
It's not like <> would not work there as well, is it?
> Some people write triplets without the '3' as {c8*2/3 d e}
> so they depend on LilyPond remembering the *n/m with the
> duration.
I have no idea who "some people" are, but that does seem like a valid
use pattern.
> <> is less transparent, because a thoughtful user would
> expect it to have the same duration of the previous note
> or chord, or to be a syntax error.
The question is whether <> is recognizable as a chord at all or _does_
look like, say, an Ada boxcar
<URL:http://en.wikibooks.org/wiki/Ada_Programming/Delimiters/box>. Now
\displayLilyMusic will show <c d e>4 as < c d e >4, so there is a
reasonable case for letting <> display as < > in order not to hand the
"it's a bird, it's a plane, it's a token" fans more than the legally
required amount of support.
Since \displayLilyMusic is probably mostly intended as an educational
tool and because of the mentioned consistency, I am sympathetic to
changing its output.
For the manual, I am more skeptical. This reflects human usage, and
a) we do write <c e g> everywhere, so < > seems inconsistent
b) between < and > is an awful place to wrap lines, probably one of the
reasons for a)
c) <>\footnote ... makes for a more consistent visual unit than <
>\footnote ..., I mean < >\footnote ..., though indeed < and > still
have considerable optical power to form a unit even with a space in
between.
--
David Kastrup
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
