LM 2.4.1: More accurate description of variable naming rules

LM 2.4.1: More accurate description of variable naming rules

The previous wording was incorrect in disallowing dashes and underscores
in principle.  I took this more verbose explanation from a suggestion
by Johan Vromans, which shows more of possibilities currently available.
I didn't include the part to disclose the more confusing, much debated syntax with double quotes.
See http://lists.gnu.org/archive/html/lilypond-user/2015-12/msg00656.html &c.

[simon.albrecht, 2015-12-29 16:09:53]

Patches unchanged, only testing git cl.

[simon.albrecht, 2015-12-29 16:14:09]

Please review.
I tried to make a sensible compromise based on the recent user list discussion.

[dak, 2015-12-29 16:35:25]

https://codereview.appspot.com/280560043/diff/20001/Documentation/learning/co...
File Documentation/learning/common-notation.itely (right):

https://codereview.appspot.com/280560043/diff/20001/Documentation/learning/co...
Documentation/learning/common-notation.itely:1343: The name of a variable must
consist of alphabetic characters, underscores
I think that this is the wrong place for this description because you are not
talking about a "variable" but rather about LilyPond's idea of identifiers. 
Those are not just used for "variables" (which are usually understood as music
expressions) but for markup commands, note names, layout/output settings, grob
names, context names, context property names, grob property names, music
function names, engraver and translator names, context modification names.  We
have a number of conventions for the various different kinds of identifiers
here.

I don't think we are doing people a favor by dropping the definition of the
general identifier syntax here at the point music variables are introduced
without giving any guidance about what actually is commonly used for what
purpose.  That does not help in understanding other people's files, and it does
not help in writing one's own files in a manner where others will get the intent
without some double takes.

[thomasmorley651, 2015-12-29 17:11:45]

https://codereview.appspot.com/280560043/diff/20001/Documentation/learning/co...
File Documentation/learning/common-notation.itely (right):

https://codereview.appspot.com/280560043/diff/20001/Documentation/learning/co...
Documentation/learning/common-notation.itely:1343: The name of a variable must
consist of alphabetic characters, underscores
Although I'm pretty guilty to do it different myself quite often, I think we
should advice a starting user (and this is the user the LearningManual is
thought for) to follow a certain convention, i.e. alpabatic characters only!
Conventions _are_ use- and helpfull. If you do it different you better know what
you're doing. But can we expect this from a starter?
Can we expect from a starter to take care not to match an internal keyword? How
should he know?

We may explain other possibilities, elsewhere. Though, I'd have no problem to
hide it in ... say Snippets or LSR.

It's a rare case something like 
mus¹ = <some-music> or
"mus-1" = <some-other-music>
is really helpfull.

We already propose naming conventions:
LM 4.1.3
NR 5.2.4
Why not point to the usage of alphabetic-characters-only in the LM as a
convention as well? Without explicit examples or deeper explanations.

[pkx166h, 2015-12-29 22:01:10]

https://codereview.appspot.com/280560043/diff/20001/Documentation/learning/co...
File Documentation/learning/common-notation.itely (right):

https://codereview.appspot.com/280560043/diff/20001/Documentation/learning/co...
Documentation/learning/common-notation.itely:1347: 
I'd probably concur with this for the Learning Manual.

Just keep it simple, then use an @ref to the Notation and explain it more detail
there.

[simon.albrecht, 2016-01-03 23:21:51]

On 29.12.2015 23:01, pkx166h@gmail.com wrote:
>
>
https://codereview.appspot.com/280560043/diff/20001/Documentation/learning/co...

>
> File Documentation/learning/common-notation.itely (right):
>
>
https://codereview.appspot.com/280560043/diff/20001/Documentation/learning/co...

>
> Documentation/learning/common-notation.itely:1347:
> I'd probably concur with this for the Learning Manual.
>
> Just keep it simple, then use an @ref to the Notation and explain it
> more detail there.

Thanks for your opinions. I’ve made a new attempt now; unfortunately, 
after some juggling around with git operations I can’t reliably handle 
yet I had to open a new issue for review: 
<https://codereview.appspot.com/284070043/>. I’m closing this one.

Best, Simon