[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: fatal error with toplevel-markup-identifier

From: David Kastrup
Subject: Re: fatal error with toplevel-markup-identifier
Date: Wed, 14 Aug 2013 21:03:41 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux)

Thomas Morley <address@hidden> 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

But since \ needs to make a choice about the syntactic class right away,
that does not work like with #.

David Kastrup

reply via email to

[Prev in Thread] Current Thread [Next in Thread]