> I strongly disagree :-) > When there is an error, the default should be to continue as long as > possible. For large projects where the compilation takes time, you want > to have some viewable output even if there is a glitch somewhere. I also > think you are overestimating the "developing effort" -- such an option > would be absolutely trivial to add. I am not sure it is worth it though. > As David said, hiding errors is always a heuristic process. I think this > would be better addressed by a convenient "jump to first error" button > in Frescobaldi.
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. On mar. 29 2022, at 8:53 am, Jean Abou Samra <j...@abou-samra.fr> wrote: > Le 29/03/2022 à 08:46, Martín Rincón Botero a écrit : > > +1. I think making it customizable (with a --cascade-level parameter) > > wouldn't add much value considering developing effort, though. > > Lilypond, like Python f. ex., should simply report the first error > > (and ideally immediately abort compilation). > > > I strongly disagree :-) > When there is an error, the default should be to continue as long as > possible. For large projects where the compilation takes time, you want > to have some viewable output even if there is a glitch somewhere. I also > think you are overestimating the "developing effort" -- such an option > would be absolutely trivial to add. I am not sure it is worth it though. > As David said, hiding errors is always a heuristic process. I think this > would be better addressed by a convenient "jump to first error" button > in Frescobaldi. > > Jean
