ly:parser-include-string and include order...
Hi, This came up while debugging an issue in Frescobaldi's layout control options panel (I'm updating it to be compatible with LilyPond 2.23). $ ls included1.ily included2.ily include-order.ly $ cat include-order.ly \version "2.25.0" #(begin (define (inc filename) (ly:parser-include-string (format #f "\\include \"~a\"" filename))) (inc "./included1.ily") (inc "./included2.ily")) $ cat included1.ily \version "2.25.0" #(ly:message "included1.ily parsed") $ cat included2.ily \version "2.25.0" #(ly:message "included2.ily parsed") $ LC_ALL=C.UTF-8 ~/repos/lilypond/build/out/bin/lilypond include-order.ly GNU LilyPond 2.25.0 (running Guile 3.0) Processing `include-order.ly' Parsing... included2.ily parsed included1.ily parsed Success: compilation successfully completed Notice in the log how included2.ily is parsed *before* included1.ily. On the other hand, putting the two calls to ly:parser-include-string in separate Scheme forms instead of using begin yields the right order: #(define (inc filename) (ly:parser-include-string (format #f "\\include \"~a\"" filename))) #(inc "./included1.ily") #(inc "./included2.ily") => included1.ily parsed included2.ily parsed My understanding of what happens in the first case is that after the first ly:parser-include-string is executed, the parser is in a state where its current file is included1.ily, and the \include "included2.ily" instruction actually gets inserted at the beginning of included1.ily. Does anyone with more knowledge of the parser than me have an opinion on which of these to do? a) Open an issue; this is a problem that should be fixed. b) Open an enhancement request about adding a proper interface for programmatically including a file. I know you can do #{ \include #x #}, but this is not the desired effect for Frescobaldi: it loads the LilyPond code inside a #{ #} context. c) Declare that this is fraught with difficulties and users should Just Not Do That (™). Thanks, Jean OpenPGP_signature Description: OpenPGP digital signature
Re: Another user complaint about incompatible mark-like events
Le 03/12/2022 à 16:18, Dan Eble a écrit : On Dec 3, 2022, at 08:48, Jean Abou Samra wrote: It rejects the \sectionLabel that comes at the same time as an implicit \codaMark. Printing "Coda" instead of a coda mark is the defining use case for \sectionLabel. I'll try to take a closer look at the example soon. I've opened https://gitlab.com/lilypond/lilypond/-/issues/6480 to record it. OpenPGP_signature Description: OpenPGP digital signature
Re: Plan for releasing 2.24.0
On Thu, 2022-12-08 at 22:45 +0100, Jean Abou Samra wrote: > Le 08/12/2022 à 20:08, Jonas Hahnfeld via Discussions on LilyPond > development a écrit : > > Until Sunday, December 11th: > > - merge https://gitlab.com/lilypond/lilypond/-/merge_requests/1710 and > > other release preparations (VERSION, convert-ly rule, something else?) > > > https://lilypond.org/doc/v2.23/Documentation/contributor/major-release-checklist > lists a few things not to forget. Much of it looks outdated, though. Yes, I'm taking notes to update that page after the stable release is done. signature.asc Description: This is a digitally signed message part