Be more explicit about footnotes on chord constituents

Be more explicit about footnotes on chord constituents

This tries to deal with the suggestions stemming from the
<URL:http://lists.gnu.org/archive/html/lilypond-user/2013-01/msg00021.html>
discussion.  It also rewords a bit of following documentation.

[pkx166h, 2013-01-02 12:51:05]

coming from a 'not developer's' point of view.

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.it...
Documentation/notation/input.itely:1338: 
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).

https://codereview.appspot.com/7038047/diff/1/Documentation/notation/input.it...
Documentation/notation/input.itely:1403: footnote.  A @samp{NoteHead} is the
(only) grob directly caused
Don't see the point of the parenthesis here for '(only)' - I don't think we need
to pussy-foot here.

https://codereview.appspot.com/7038047/diff/1/Documentation/notation/input.it...
Documentation/notation/input.itely:1422: ees fis
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?

[Trevor Daniels, 2013-01-02 14:06:16]

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.it...
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.it...
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).

[dak, 2013-03-05 16:25:06]

I hate it when I discover I had unpublished draft comments on an issue that has
been closed long ago.  I am flushing out these comments nevertheless for the
record so that reviewers don't think I ignored their feedback (rather than being
of different opinion on most points, and having changed the text where I agree).

If it turns out that the disagreement was not satisfactorily addressed by those
comments, we can still put out another iteration.

Sorry.

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.it...
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 no[t] what doesn't (if you see what I mean).

It is not a "known issue" since everything works perfectly according to design
and intent, and so the user deserves to know what this design entails.

It is not a side-effect or bug that you can't annotate a chord as a whole, but
entirely intentional.  As one consequence of this design, you can put together a
chord using parallel music, namely <<...>> (moving durations and articulations
inside) instead of <...>.

You don't need a chord construct in the input to hold notes together.

A "known issue" is something for cases where there would be good reason for
things to be different.

But there is, for example, no way where we could write
<<\tweak font-size #-3 <c e> <g a> >>
and ever have the font size tweak apply only to the first two notes and not to
the last two notes: all of them will be assembled into a single chord.

https://codereview.appspot.com/7038047/diff/1/Documentation/notation/input.it...
Documentation/notation/input.itely:1403: footnote.  A @samp{NoteHead} is the
(only) grob directly caused
On 2013/01/02 12:51:05, J_lowe wrote:
> Don't see the point of the parenthesis here for '(only)' - I don't think we
need
> to pussy-foot here.

Fair 'nuff.  Will do, but does not warrant a new upload on its own.

https://codereview.appspot.com/7038047/diff/1/Documentation/notation/input.it...
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?

"\single" is not a "collection of overrides", it is a collection of overrides
(including a single override) converted into a collection of tweaks.

It is somewhat wartish that you need to employ it for some special case of
footnote, but since that case is rather common, I don't think it makes sense to
ban it into snippets, like we also don't ban any example making use of
"\once\override" instead of just "\override" into snippets.

Yes, our manuals are too large, but I don't think that removing this usage
(which incidentally was originally covered by a different syntax getting along
without \single) is worth the trouble caused by the removal.  People are already
having enough of a problem using footnotes with confidence.