Separate out paper settings?

[uliska]

I've started working with lyluatex again in a large-scale project, and I must say I'm amazed how (some glitches admitted) easy and powerful the integration actually works. (I think there will be some further enhancements I'll contribute over the coming months).

One thing I notice is: I'm basically working with \lilypondfile in order to maintain my music examples separately in the directory tree and to be able to prepare them using Frescobaldi. What I'm looking for is a way to automate the process of having the same layout parameters in Frescobaldi as when compiling through lyluatex.

I have some ideas and could probably get something done for my project at hand, but ideally there would be a generally usable solution to be included in lyluatex. The basic idea would be to have one resource that is used from both perspectives.

The approach that currently looks the most promising to me (although it would probably need quite some validation and fallback procedures) is (only for \lilypondfile):

• Do not write the generated paper variables to the generated .ly file
• Write it to an include file instead and place this next to the requested LilyPond input file
• Write an \include statement pointing to the previously generated file into the temp file

This way the actual paper variables are available from the original input file after the first run of lyluatex.

Issues I can see right now:

• The include file has to be included by the main input file.
  • The user would have to actively do that (error prone)
  • It has to be ensured that this doesn't lead to two include statements in the .ly file generated by lyluatex
• This approach would probably fail when one example is to be used from multiple documents
• It might be considered intrusive to create a permanent file in the user file's directory. (And we have to consider possible conflicts with existing files). So it should be optional and disabled by default (it's only needed when the user wants to prepare examples with the same page layout features (for example to judge line breaking).
• [Probably more to come ...]

The double include issue could probably be solved by checking for such an include statement since we are in control over the filename.

A workaround from the other perspective would be to not require an explicit \include statement but teach Frescobaldi (creating an extension (using the new API)) to transparently inject it upon compilation. That would alleviate the "has to do it manually" issue but has substantial drawbacks: it would be application-specific, and it would essentially require a new "compilation mode" specifically for lyluatex.

@jperon What do you think?

[rpspringuel]

This sort of situation is why I put the inside-lyluatex conditional into the automatically inserted header. This allows me to have #(if (not (defined? 'inside-lyluatex)) ...) blocks inside my project style file (which gets included into every score in the project). Said blocks only get executed when I'm working on the score directly (usually in Frescobaldi) and have no effect when I'm working in the LuaLaTeX project.

Right now, I use these blocks to define reasonable approximations of the final environment (for instance, using a5 paper, because that's approximately the size of the final project). My scores are simple enough (very few, if any, manual tweaks) that I don't need to see the exact end result when editing in Frescobaldi. However, said conditional might be useful for creating something more automated.

[jperon]

Perhaps another approach would be to have:

1. some pseudo-comments that would be ignored by lyluatex when compiling the score (something like %lyluatex-ignore on / %lyluatex-ignore off);
2. a new option (something like write-headers) to have the headers written in a special file within tmp-ly, without changing actual behavior otherwise: I don't think it would be necessary to replace headers by \include within lyluatex's temporary scores.

That way, one could add the following to his source file:

%lyluatex-ignore on
\include "GENERATED_HEADERS.ly"
%lyluatex-ignore off

Perhaps it wouldn't even be necessary to define those pseudo-comments: as stated by @rpspringuel, #(if (not (defined? 'inside-lyluatex)) ...) could do the trick, and implementing 2. would be enough.

[jperon]

233 is just a proposal to implement 2. as stated above; feel free to comment, modify or reject it.