Re: [Lilypond-auto] Issue 2702 in lilypond: Patch: Unify the lexer's idea of words and commands across all modes.

[lilypond]

Comment #6 on issue 2702 by address@hidden: Patch: Unify the lexer's idea of  
words and commands across all modes.
http://code.google.com/p/lilypond/issues/detail?id=2702

Here are some thoughts behind this:

convert-ly and editors and other interpreters of LilyPond rarely know what  
mode LilyPond's lexer is supposed to be in.  As one consequence, we can't  
even support this change with rules that are likely to fix more things than  
they break.

If we prohibit consecutive - or _, this makes it more likely that in music  
notes stuff like -- or __ or -_ does not accidentally become part of a  
name.  Also -- and __ have special meaning in lyrics mode.

Prohibiting - or _ at the end of a word is inevitable or lots of music  
would become invalid, like c-. would (it would become the word c- followed  
by .).  Since they are more naturally prohibited at the start of the word,  
this makes for some symmetry.

There are quite a number of commands with - in them.  There are only very  
few commands and words containing _ I think, almost exclusively engraver  
names (most of them however are referenced using quoted strings, or in the  
case of Scheme engravers, using # rather than \).  It would be feasible to  
declare the few uses of _ as unsupported and change them.  Since we need to  
support - anyway and its problems appear to be a superset of the problems  
with _, I picked _ as well.  It does seem consistent to be able to write a  
LilyPond entity like an engraver as an unquoted word.

It would have been feasible to include . in this set in order to turn  
Voice.Accidental into a word.  However, I want to retain the option of  
turning it into #'(Voice Accidental) or #'("Voice" "Accidental") instead,  
and there does not seem to be a need for dots in command names.

That does not mean that now defining music functions with - would be a good  
idea.  It makes sense keeping the naming conventions, and there are  
entities one may want to define or use in the (initial) notes mode that  
will get used elsewhere.

It seems rather awkward that one can't use #{ \page-width #} in layout  
definitions for the sole reason that it gets parsed as #{ \page - width  
#}.  And #{ #page-width #} does not work inside of functions because then  
page-width in the current lexical closure instead of the dynamic  
environment is consulted.

This is an incompatibility with previous undocumented semantics.  But I  
consider it a good pitch for semantics worth to document and support that  
are hopefully reasonably compatible with the documents people dared to  
write so far.

What I don't like is that I don't see a good way to move forward with  
changes like this in a reasonably democratically legitimized manner, given  
the amount of actual feedback.  Now one angle of GLISS is to decide what  
parts of existing syntax may be declared as dependable/final.  I think that  
the state after this patch is a much better candidate for finalizing than  
the state before it.

So I'd like to see it in a 2.16 release candidate.  Like with other  
potentially disruptive changes, I don't see that I can do much better than  
putting it out for review and, depending on that, move forward.