error: unknown escaped string:... after defining a variable

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

error: unknown escaped string:... after defining a variable

Eluze
with

\version "2.19.0"
A={c d e}
\A

I get the message "error: unknown escaped string: `\A'"

putting something substantial(?) like a markup or another definition after the definition the variable A can be used without brackets:

\version "2.19.0"
A={c d e}
A={c d e}
\A

is this a bug, remediable?

Eluze
Reply | Threaded
Open this post in threaded view
|

Re: error: unknown escaped string:... after defining a variable

David Kastrup
Eluze <[hidden email]> writes:

> with
>
> \version "2.19.0"
> A={c d e}
> \A
>
> I get the message "error: unknown escaped string: `\A'"
>
> putting something substantial(?) like a markup or another definition after
> the definition the variable A can be used without brackets:
>
> \version "2.19.0"
> A={c d e}
> A={c d e}
> \A
>
> is this a bug, remediable?

Not a bug, not remediable.

A={c d e}
\addlyrics { this is bad }

would be legitimate, so the assignment is not complete without looking
at the next token, and the next token is \A which is not defined.

--
David Kastrup


_______________________________________________
bug-lilypond mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Reply | Threaded
Open this post in threaded view
|

Re: error: unknown escaped string:... after defining a variable

Eluze
David Kastrup wrote
A={c d e}
\addlyrics { this is bad }

would be legitimate, so the assignment is not complete without looking
at the next token, and the next token is \A which is not defined.
how then would you complete an assignment or hinder  \addlyrics { this is bad }  to be assigned to A?

Eluze


Reply | Threaded
Open this post in threaded view
|

Re: error: unknown escaped string:... after defining a variable

David Kastrup
Eluze <[hidden email]> writes:

> David Kastrup wrote
>> A={c d e}
>> \addlyrics { this is bad }
>>
>> would be legitimate, so the assignment is not complete without looking
>> at the next token, and the next token is \A which is not defined.
>
> how then would you complete an assignment or hinder  \addlyrics { this is
> bad }  to be assigned to A?

\addlyrics does not make any sense outside of the assignment.  If it is
there, it has to go to the end of A.  Other than that, the assignment is
complete when anything but \addlyrics comes up.  I don't think that

x=...
\x

without anything intervening makes all that much sense, and since one
cannot put a pure
\addlyrics ...
into a variable anyway, one could claim that LilyPond should stop
looking for \addlyrics when seeing \x.  But the point is that we have
_two_ parts of LilyPond involved here, lexer and parser, and the parser
does not get to see \x at all before the lexer has made a decision about
its type, and for making that decision, it needs to look at its value.

--
David Kastrup


_______________________________________________
bug-lilypond mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Reply | Threaded
Open this post in threaded view
|

Re: error: unknown escaped string:... after defining a variable

Eluze
David Kastrup wrote
Eluze <[hidden email]> writes:

> David Kastrup wrote
>> A={c d e}
>> \addlyrics { this is bad }
>>
>> would be legitimate, so the assignment is not complete without looking
>> at the next token, and the next token is \A which is not defined.
>
> how then would you complete an assignment or hinder  \addlyrics { this is
> bad }  to be assigned to A?

\addlyrics does not make any sense outside of the assignment.  If it is
there, it has to go to the end of A.  Other than that, the assignment is
complete when anything but \addlyrics comes up.  I don't think that

x=...
\x

without anything intervening makes all that much sense, and since one
cannot put a pure
\addlyrics ...
into a variable anyway, one could claim that LilyPond should stop
looking for \addlyrics when seeing \x.  But the point is that we have
_two_ parts of LilyPond involved here, lexer and parser, and the parser
does not get to see \x at all before the lexer has made a decision about
its type, and for making that decision, it needs to look at its value.
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={...}

can we conclude that it's best (or simplest) to always put a space after the variable name being assigned a value?

Eluze
Reply | Threaded
Open this post in threaded view
|

Re: error: unknown escaped string:... after defining a variable

David Kastrup
Eluze <[hidden email]> 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
[hidden email]
https://lists.gnu.org/mailman/listinfo/bug-lilypond