David Kastrup <[email protected]> writes:
> Carl Sorensen <[email protected]> writes:
>
>> Actually, [c16 d e f] is *not* valid lilypond. The first brace needs to
>> come after the c16:
>
>> So I don't think there's a problem with the options coming after the
>> {lilypond}.
>
> Oh right. Wow.
Took a look at lilypond-book.py. Did one change and am just now
recompiling.
The change is fairly obvious (hope it works):
diff --git a/scripts/lilypond-book.py b/scripts/lilypond-book.py
index b4bd319..da13ab9 100644
--- a/scripts/lilypond-book.py
+++ b/scripts/lilypond-book.py
@@ -467,7 +467,10 @@ snippet_res = {
\\begin\s*(
\[
\s*(?P<options>.*?)\s*
- \])?\s*{lilypond}
+ \])?\s*{lilypond}(?(options)|(\s*
+ \[
+ \s*(?P<options>.*?)\s*
+ \])?)
(?P<code>.*?)
^[^%\n]*?
\\end\s*{lilypond})''',
However, I am doing this more or less pattern-based without any
knowledge of the program structure, and lilypond-book.py _also_ contains
FILTER: r'''\begin{lilypond}[%(options)s]
%(code)s
\end{lilypond}''',
which already _has_ the normal LaTeX order for some reason. So what
gives?
--
David Kastrup
_______________________________________________
lilypond-devel mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/lilypond-devel
