> Sometimes I want to see the output inspite of errors. Aborting > immediately if there is a syntax problem is definitely not always the > best solution. I fully agree with other people that it should be > Frescobaldi's job to jump to the first error message (in case it > doesn't do this already).
I would tend to sympathize with that personal preference if producing PDF output was fast or if time was abundant. Worse than waiting for Lilypond to compile is waiting for Lilypond to produce a visually corrupted PDF. > Simply check LilyPond's return value. If it is non-zero you know > there is a problem. On the other hand, having visual output in case > of errors sometimes help identify where and what the problem is. I'm lucky to be able to work using Lilypond through Python. I never compile the whole score I'm working on, but only the current "segment" (around 2 pages) and the corresponding pages get updated in the PDF. Compiling the whole thing is something I do only at the end of a project because it's so slow (I believe TeX suffers from similar problems, so mentioning TeX doesn't really improve the situation). Now your idea is a very good one, and I'll implemented in my own Python algorithms (which will essentially make Lilypond work twice: once without \score blocks and once with \score blocks). I just checked: a 20 pages project takes about 30 seconds to compile. Compiling Lilypond without a \score block takes about 1 second. If in the same project I misspell the word "\tuplet" for example, with a \score block it won't stop compiling and will continue until, voilà, you get a corrupted PDF. 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. —Martín. On mar. 29 2022, at 11:10 am, Werner LEMBERG <w...@gnu.org> wrote: > > > 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? > > Sometimes I want to see the output inspite of errors. Aborting > immediately if there is a syntax problem is definitely not always the > best solution. I fully agree with other people that it should be > Frescobaldi's job to jump to the first error message (in case it > doesn't do this already). > > > 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. > > Simply check LilyPond's return value. If it is non-zero you know > there is a problem. On the other hand, having visual output in case > of errors sometimes help identify where and what the problem is. > > TeX behaves quite similarly; IDEs for TeX also have the ability to > jump to errors. > > > Werner
