lilypond-user
[Top][All Lists]
Advanced

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

Re: Lilypond error behaviour


From: Thomas Morley
Subject: Re: Lilypond error behaviour
Date: Sun, 17 Apr 2016 16:20:27 +0200

2016-04-17 13:59 GMT+02:00  <address@hidden>:
> On Sun, 17 Apr 2016, Urs Liska wrote:
>> No, of course not. If LilyPond is able to "recover" (as Andrew put it) it
>> should of course do so. But it should not report a "fatal error" and a
>> "failed file" then.
>
> I think the whole thing comes down to something very simple which
> ought to go without saying, but evidently needs to be said after all:
>
> Lilypond should not lie.

Does she?

Look at the sippet below where I accumulated several errors:

%%%% snippet start

\version "1.7.2"

(display "whatever")

\foo

{ c''1 }
{

#(format #t "~a\n"
  (assoc 'avoid-slur (assoc-get 'Accidental all-grob-descriptions)))

%{

%%%% snippet end !!

In terminal I see:

(1) for the version:

error: file too old: 1.7.2 (oldest supported: 2.7.38)
error: consider updating the input with the convert-ly script

(2) for `(display "whatever")' without leading #-sign

atest-218.ly:3:1: error: syntax error, unexpected EVENT_IDENTIFIER

(display "whatever")

(3) for the call of undefined `foo'

atest-218.ly:5:1: error: unknown escaped string: `\foo'

\foo

(4) for the opening `{' followed by #(format ...)

(avoid-slur . inside)
atest-218.ly:10:1: warning: Ignoring non-music expression

#(format #t "~a\n"

(5) for the not finished block-comment

atest-218.ly:13:3: error: EOF found inside a comment
%{

atest-218.ly:13:3: error: syntax error, unexpected end of input
%{

All of them are "non_fatal_error" errors, correctly reported! LilyPond
continues outputting a pdf.
In the very end she throws a more or less summarizing _fatal_ error _and_ exits.
`Success: compilation successfully completed' is missing!
(Or look in flower/warn.cc and lily/lexer.ll)

It's LilyPonds most important goal to produce some printed output. And
she succeeds even by such a messy input.
The reason throwing the fatal error but not exiting before is
explained in the CG-link Simon already provided.

Is it a lie throwing such an summarizing fatal error in order to
protect our user-, bug- and devel-mailing-lists from users not paying
attention what they are told by non_fatal_errors (and warnings)?
I know several examples where people continued happily ignoring all
until the file contained several thousand lines and finally something
in that mess caused an _immidiate_ fatal error. Then they shine up on
mailing-lists and forums complaining and asking for help.

Otoh, I think I understand why Andrew needs to triage the differently
severe errors.
But the only thing I can think of is to treat _any_ error/warning as
fatal setting
#(ly:set-option 'warning-as-error)
or using the command-line version
-dwarning-as-error


Cheers,
  Harm



reply via email to

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