jperon / lyluatex

Alternative à lilypond-book pour lualatex
MIT License
58 stars 12 forks source link

Handling LilyPond compilation failures #30

Closed uliska closed 6 years ago

uliska commented 6 years ago

When a LilyPond compilation fails a Lua stack trace occurs in write_tex because it tries to read non-existent files.

This should be handled by at least suppressing the error. Of course the user should somehow be notified. In musicexamples missing files don't cause an error but an information box is printed instead. I think something similar to that would be a good idea.

rpspringuel commented 6 years ago

I prefer that an error be raised when a non-existent file is trying to be read. Whether the error is a lua stack trace or a more readable package error doesn't bother me much.

However, now that I think about it, I can also see the benefit of doing something like what musicexamples does for the purpose of creating placeholders in a skeletal document, but I want that to be optional behavior. Perhaps a draft and/or demo option (and/or keyword argument) would be useful behavior. This is what the graphics/graphicx package does. In that package draft means "Do not include graphics files, but instead print a box of the size the graphic would take up, and the file name." while demo is "Instead of including a graphics file, make \includegraphics insert a black rectangle of size 150 pt by 100 pt unless either dimension was already specified by another option." demo is a package-level option only, draft is both a package-level option, and a keyword available for each \includegraphics command (when using the graphicx version which supports keywords). We could make both available at both levels, however.

uliska commented 6 years ago

I prefer that an error be raised when a non-existent file is trying to be read.

OK, I prefer not interrupting the compilation - so this clearly speaks for making both behaviours possible ;-)

Whether the error is a lua stack trace or a more readable package error doesn't bother me much.

It definitely should be more readable, as that stack trace is pretty confusing for regular users.

However, now that I think about it, I can also see the benefit of doing something like what musicexamples does for the purpose of creating placeholders in a skeletal document,

That touches a point I've noticed these days. Every now and then I think about implementing something that musicexamples does (or plans to do). However, I think we should try to avoid duplication of concerns as much as possible, but this issue shows that it may be more complex than would be desirable. Basically lyluatex should not produce that yellow placeholder but do something that can make musicexamples do so. BUT: the point in keeping the two packages separate is to enable them to work without the other. So what would lyluatex do if musicexamples is not present?

Actually I think we should not think this through from the perspective of this current issue item but keep it in mind for a later discussion about the interaction of the two packages in general. I would like to get more familiar with lyluatex first, maybe making some more contributions, and then go through musicexamples again, probably updating it significantly (probably quite a lot of the code was still pretty naive ...). Then we should discuss the relation of the two packages more generally.

jperon commented 6 years ago

@uliska Would you like to implement other things on this issue, or may we close it ?

uliska commented 6 years ago

I will think about it, I had one more idea.

uliska commented 6 years ago

Actually it's not necessary to keep this one open. @rpspringuel wants an error to occur (which is the default behaviour), and alternatively a box is printed (which is what I would usually want).

If anybody ever wants some other behaviour they can open a new issue.