Fix #230

[jperon]

Have the headers written to a separate file so that users may include them manually while writing on scores, and get the final result.

[jperon]

@uliska Do you think this solves your issue ?

[jperon]

@uliska Would you mind either merge or close this PR before #243 gets too far ? I'd like to avoid possible conflicts when changes get bigger.

[uliska]

Sorry for leaving this so far behind - especially since it is about a request of mine.

I like the output in the file, and I think that part can be kept unchanged (although I didn't try very hard to test it with complicated option combinations).

However, I think it is somewhat fruitless to save this as to output..'-headers.ly' since that is not only inconvenient to access through .list file but in particular it is so volatile. The target filename will change with any modification to the LilyPond code and even the inclusion options.

I think including the headers really is only useful when preparing the score in an external file, and it will only be relevant in examples of such dimensions that they will typically be included as external files. So the headers should not be put in the tmpdir but in the user space. My suggestion would be one out of

• <input-filename>-lyluatex-headers.ily
• path/to/directory/<filename>-lyluatex-headers.ily (if a certain option is set)
• path/to/explicit/filename.ily

The second and third could be absolute or relative paths as usual (although one could argue whether relative paths should be relative to the LilyPond or the compiled LaTeX file). The reasoning behind the last option is that in many cases when you have many examples in one document the headers will be identical. So what I would probably have in most projects is a fixed file as package option and override that locally when necessary (eg. when an example needs some indent or different staffsize).

---

Yes, this is a valuable thing, and I assume I'd use it all the time. In my current project it is not that much of a problem but in a number of cases the different sizes in Frescobaldi and LaTex just makes the difference between one-system and one-system-plus-one-measure scores, which would be great to be able to fine-tune in Frescobaldi.

Once this is in place here I will probably write some syntactic sugar for use in LilyPond (probably a tiny openLilyLib package) that can include the headers if not compiled through lyluatex.

PS: For testing I merged master into your branch, and that worked, so I suggest pushing that to minimize any risks of later merge conflicts

[jperon]

@uliska Should be ready for merge: write-headers now takes a value, that's the destination dir of the file. For example, with this mwe, headers will be written to headers/test-lyluatex-headers.ily:

\documentclass{scrartcl}
\usepackage[write-headers=headers]{lyluatex}

\begin{document}
\lilypondfile{test.ly}
\end{document}

The path may be absolute (/tmp/headers would work); if not, it's relative to the current dir, which means the dir from which lualatex is launched (same as tmpdir). Incidentally, this let me enhance tmpdir: this can now be absolute too.

Perhaps there would be conflicts with #243; never mind, merge it if it works, and then I'll deal with conflicts while reviewing #243.

[uliska]

I'm out of town today, just wanted to let you know. -- Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.

[jperon]

@uliska If you agree with that, I think it should be ready for merge. If possible, prefer "Squash and merge" over single "merge" (to clarify history).

[uliska]

I've just added a check to prevent an error when having a score without filename.

There's one more thing I'll add in a minute: an explicit filename for the headers, as detailed in https://github.com/jperon/lyluatex/pull/233#issuecomment-492398532

[uliska]

@jperon Due to some more changes I'd like to give it back to you for final consideration and merging.

[jperon]

@uliska The only changes I did are merely cosmetic, excepted that, instead of a global lyluatex_opt, I put a local _opt to minimize typing and avoid useless global variable.

[uliska]

Well, I did intend to directly use that global variable in a depending follow-up package, but I see that it is cleaner to not do that and re-require the module a second time.

[jperon]

IMHO, there should be two cases:

• either you want to get an option defined in lyluatex.sty or lyluatex.lua: then you'll get it from Score, or even from ly_opts;
• or you want to use methods (optlib.is_dim and so on) or define a new set of options, and then yes, you should require the module again.