Re: [bug] erroneous error messages

[Carl Sorensen]

On Mon, 2004-08-16 at 07:10, Juergen Reuter wrote:

> Hence, lily should ideally just report an error nearby line 4.  This 
> could be (depending on the strength and structure of the input syntax 
> definition) either a syntax error during parse phase (e.g. "unexpected 
> '='") or a semantical error during interpreting phase (e.g. "unknown 
> escaped sequence").  BTW, to my knowledge, classical compilers typically 
> do not try to enter any further stage after parsing phase if there occurs 
> a syntax error during parsing, but rather abort after parsing to avoid any 
> further misleading semantical error messages.
> 
> For the above example, lily reports:
> 
>   Now processing `bug.ly'
>   Parsing...
> 
>   bug.ly:4:14: error: parse error, unexpected STRING_IDENTIFIER:
>           \inputencodin
>                        g = "latin1"
>   Interpreting music... [1]
>   Preprocessing graphical objects... 
>   Calculating line breaks... [2]

I believe that this error is exactly what you ask for.  You mention
above that the error should be something like "unknown escaped
sequence".  But it points out in the manual that

"By using variables, also known as identifiers, it is possible to break
up complex music expressions. An identifier is assigned as follows

     namedMusic = { ... }

The contents of the music expression namedMusic, can be used later by
preceding the name with a backslash, i.e., \namedMusic. In the next
example, a two-note motive is repeated two times by using variable
substitution ..."  (see
http://lilypond.org/doc/v2.3/Documentation/user/out-www/lilypond/Organizing-larger-pieces.html#Organizing-larger-pieces)

The syntax error here is that it gets an identifier (\inputencoding) at
a place where it isn't expected.  And that's just what lily tells us.

> However, the additional warning 
> about the non-matching braces around \score while converting to "bug.pdf" 
> is completely irritating. 

I, too, sometimes worry about the remaining errors, which are the result
of the first one.  Of course, if you've ever left a semicolon out of a
line of C code, you've seen pages and pages of irrelevant error
messages, so you know to go right to the first one, recompile, and see
what happens.  I understand that much, perhaps most, of the intended
audience for lilypond consists of non-programmers.  IMO, that is the
major difficulty with lilypond -- it has a programming-based worldview. 
Writing a score is similar to writing a program.

However, much of the time when lilypond keeps on going after finding a
syntax error, it produces useful debug output.  Of course it won't be
entirely correct, but I can often kill two or three bugs with a single
lilypond invocation.  I, at least,  prefer the current behavior to
having the execution stop as soon as an error occurs.

Carl Sorensen