"Trevor Daniels" <t.dani...@treda.co.uk> writes: [...]
> Let's forget the unrealistic convoluted examples and look > at a real case where s1*0 is necessary and is used in the > docs (taken from > http://www.lilypond.org/doc/v2.14/Documentation/notation/common-notation-for-keyboards > ) > > It's needed when a crescendo ends on the final note in a > music expression. The three ways of doing this are: > > \relative c' { > e2\p\< d\> s1*0\! > } > \relative c' { > e2\p\< d\> <>\! > } [...] > Of the two remaining, I find s1*0 clearer than <> in this > example, so I am not in favour of a blanket change to <> > in the docs. But I am in favour of documenting the > already-existing semantics of <>. The advantage of any blanket change is that it promotes not having to think before acting. Thinking has its place, but a musician thinking about every note or a programmer thinking about every symbol are not going to be effective. "x is clearer than y in this example" views this example as independent from every other example. Would it help to write \relative c' { e2\p\< d\> < >\! } I actually don't think so. Keeping <> together makes it somewhat easier to identify it as one logical block. Would it help to write \relative c' { e2\p\cr d\decr <>\! } Absolutely, yet nobody wants to argue that. Are there situations where one would _not_ want to use or recommend \relative c' { e2\p\< d\> s1*0\! } as a building block? Absolutely: \relative c' { e2\p\< d\> s1*0\! } \addlyrics { Oh no } \relative c' { e2\p\< d\> <>\! } \addlyrics { Oh yes } delivers lilypond /tmp/test.ly GNU LilyPond 2.15.38 Processing `/tmp/test.ly' Parsing... /tmp/test.ly:0: warning: no \version statement found, please add \version "2.15.38" for future compatibility Interpreting music... /tmp/test.ly:3:18: warning: Two simultaneous lyric events, junking this one } \addlyrics { Oh no } /tmp/test.ly:3:15: warning: Previous lyric event here } \addlyrics { Oh no } Preprocessing graphical objects... Interpreting music... Preprocessing graphical objects... Finding the ideal number of pages... Fitting music on 1 page... Drawing systems... Layout output to `test.ps'... Converting to `./test.pdf'... Success: compilation successfully completed And the lyrics of the first system are missing (in spite of what the error message suggests, _both_ are missing, though for different reasons both of which will be rather hard to understand) whereas the lyrics of the second system are fine. So from a purely technical point of view, a blanket change of s1*0 to <> in the docs will leave the user with fewer concepts to learn, and with fewer surprises to expect later on. I am somewhat sympathetic to extend the parser in a manner where a music command can take an arbitrary long list of post events and thus enable a command that will do the equivalent of <>. However, there seems little point in cooking up new event types for wrapping postevents when EventChord already does exactly that, and it seems awkward to reuse the existing structure < > when \displayLilyMusic <> and \displayLilyMusic \null would be required to produce identical output. I totally don't understand the rationale for keeping the users in the dark about a technically superior (and easier to type and understand) solution for a frequent problem that works with all relevant versions of LilyPond. And I don't have the personality required for dealing with a discussion that leaves me flabbergasted at every turn. So you all can consider myself silenced on that matter, and I won't propose any patches or documentation changes regarding it. Congratulations. Though I don't really understand what you gain. -- David Kastrup _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
