Eluze <elu...@gmail.com> writes:
> maybe this example makes more sense:
>
> lyr=\lyricsto A \new Lyrics \lyricmode { this is bad. }
> mus=\new Voice= A {a b c}
> << \mus \lyr >>
>
> this triggers an error
>
> writing mus =... (with a space before the equal sign) works as well as
> enclosing the assignment before in braces:
> lyr={...}
Oh, but that's a different problem altogether. It means that the lexer
is still in lyrics mode when reading mus=. Here is a shorter example:
lyr=\lyricsto A { }
mus={ }
That's arguably a bug: \lyricsto has no business maintaining lyrics mode
beyond the closing brace as far as I can see.
> can we conclude that it's best (or simplest) to always put a space
> after the variable name being assigned a value?
In the original problem you wrote, which can be described as
A={ }
\A
no space would have helped, and in the example you showed just now, this
would be completely different behavior and could well be called a bug.
The bug should be mendable _iff_ \lyricsto A { } \addlyrics ... is
either not allowed or to be parsed as { \lyricsto A { } } \addlyrics ...
rather than \lyricsto A { { } \addlyrics ... }.
\lyricsto switches to lyrics mode for its argument, and back out of it
after the argument concludes. If it needs to look beyond the closing
brace before it can be sure about "the argument concludes", the next
token will be scanned in the wrong mode.
In fact, a file just containing
lyr=\lyricsto A { }
even makes LilyPond complain
lilypond /tmp/gaho.ly
GNU LilyPond 2.19.0
Processing `/tmp/gaho.ly'
Parsing...
/tmp/gaho.ly:1:20: error: Unfinished main input
lyr=\lyricsto A { }
/tmp/gaho.ly:1: warning: no \version statement found, please add
\version "2.19.0"
for future compatibility
fatal error: failed files: "/tmp/gaho.ly"
because LilyPond does not get out of lyrics mode in time to finish
processing the file securely (after reading the main input, LilyPond is
supposed to continue in init.ly in the mode it started with for security
reasons, so if it does not get there in the expected state, it aborts).
--
David Kastrup
_______________________________________________
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
