Comment #6 on issue 2702 by [email protected]: 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.
