Re: Feature request: Fix cascading error messages

[Jean Abou Samra]

Le 29/03/2022 à 09:31, Werner LEMBERG a écrit :
> > In this context I could imagine a paramater that kind of highlights
> > the first few error messages (or only shows the first N error
> > messages) being very forthcoming to some people without a dev
> > background. Or maybe at the end of the compilation output a clearly
> > marked: "First (few?) Error(s): ...."
> Maybe it would be sufficient to write certain keywords like 'error' or
> 'warning' with a red color – compilers like gcc or clang emit coloured
> messages, for example.



Depending on the point of view, that could be a job for
LilyPond or a GUI.

https://github.com/frescobaldi/frescobaldi/issues/681



[Martin]
> But shouldn't Lilypond check first if the syntax is correct instead of 
> spending several seconds/minutes compiling a code that's doomed to 
> visually fail? In this case, the large project argument doesn't hold. 
> Other than that, it seems we have different thresholds to what it 
> means to have usable pdf output. The "service" of a glitchy PDF that 
> Lilypond sometimes provides is of questionable value.



Sometimes it is of no value, sometimes it is. What is the
advantage in removing it?

When you start doing interesting coding in Scheme, LilyPond's
principle of "keep trying" is very because the visual symptoms
help diagnose problems in callback execution order etc.

At other times, LilyPond is unable to find the specific location
in the source that caused an error. When you get

programming error: vertical alignment called before line breaking

in the middle of the log for a sizable score, the output is the only
way to locate the problem.

For basic typos like forgotten braces, it may not be helpful,
but distinguishing such situations from less impactful errors
is less easy than you might think. Again, provided an edition
environment that makes it easy to locate problems (Frescobaldi's
red background highlighting of error lines helps me a lot) and
to view errors (Frescobaldi could improve on that point), I
don't think "keep going" hurts much.



> Why make the user wait so long to make him fix a misspelled word or 
> make him put a curly brace? A first pass should be done without \score 
> blocks and abort (or at least ask if you want to continue!) if this 
> first pass produces errors. 


As David mentioned, this is already mostly the case, the exception
being separate \book and \bookpart blocks.

The user is not blocked while waiting for the rest of the compilation
-- if you notice a trivial error, nothing stops you from aborting
the process and compiling again.



Jean