LGTM I tried to make the text as concise as possible, so it's quite expected that some expansion would be required once someone tried to grasp this from scratch.
https://codereview.appspot.com/7038047/diff/1/Documentation/notation/input.itely File Documentation/notation/input.itely (right): https://codereview.appspot.com/7038047/diff/1/Documentation/notation/input.itely#newcode1338 Documentation/notation/input.itely:1338: On 2013/01/02 12:51:05, J_lowe wrote:
Hello, I'd rather put all this as an @KNOWNISSUE only because the
document
should say what does work now what doesn't (if you see what I mean).
I don't think so. The whole reason this was added was because this limitation was insufficiently clear. Moving it to Known issues wouldn't help. https://codereview.appspot.com/7038047/diff/1/Documentation/notation/input.itely#newcode1422 Documentation/notation/input.itely:1422: ees fis On 2013/01/02 12:51:05, J_lowe wrote:
I know this wasn't a part of what you changed but Hmm...
is this just semantics or are we including what is effectively a
'snippet' here
by using \single (now that I understand single better - which is just
a
collection of overrides), if \single didn't exist today would we do
this
\footnote example by using \override and so break our
'kind-of-sort-of' rule for
not using overrides in @lilypond examples.
I.e move this whole example and the para you added as a snippet?
No need to move it to a snippet. Most of the examples would need to become snippets if we followed this logic. Once the overrides are embeddded in a predef they are fine in the main body. In any case that 'rule' applies only to the first two chapters (and fairly loosely to Chapter 2). https://codereview.appspot.com/7038047/ _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
