Thomas Morley <[email protected]> writes: > the following returns a fatal error (worked fine with 2.16.2): > > \version "2.17.24" > > mrkp = \markup { "x" } > > \mrkp > > > Terminal-output: > > GNU LilyPond 2.17.24 > Processing `toplevel-markup-identifier-bug.ly' > Parsing... > toplevel-markup-identifier-bug.ly:5:1: error: unknown escaped string: `\mrkp' > > \mrkp > toplevel-markup-identifier-bug.ly:5:6: error: syntax error, unexpected > end of input, expecting SCM_IDENTIFIER or SCM_TOKEN or STRING or '=' > \mrkp > > fatal error: failed files: "toplevel-markup-identifier-bug.ly"
Here is the rub (verified it): \markup and normal strings are no longer distinguished syntactically (in order to be able to use them interchangeably, also at top level). But for strings, there is string addition defined in assignments. You can write xxx = \markup "x" + \markup "y" as a consequence, and in your example the lookahead for the potential "+" token pulls in the \mrkp token, and since \whatever can have arbitrary token types depending on the underlying value, it proceeds to evaluate it before the assignment has been completed. I propose that we remove string addition from assignments. It's unlikely anybody was aware of it in the last 10 years, and it's not like it is documented. If you do the same with music expressions, you'll run into the same kind of problem (since most music expressions could be followed by things like \addlyrics ...). Calling variables with \ immediately after assigning potentially incomplete expressions to them will not work satisfactorily. In contrast, used within #(...) they will not be problematic usually since first the expression is read and recognized as SCM_TOKEN which is not combinable with the assignment (usually), then the assignment is executed, and only then the expression read with #(...) is evaluated and can already rely on the new value of the variable. But since \ needs to make a choice about the syntactic class right away, that does not work like with #. -- David Kastrup _______________________________________________ bug-lilypond mailing list [email protected] https://lists.gnu.org/mailman/listinfo/bug-lilypond
