Marc,
On Thu, Mar 6, 2014 at 8:40 AM, Marc Hohl <[email protected]> wrote: > Hi list, > > Am 06.03.2014 14:42, schrieb David Nalesnik: > >> Hi Marc, all, >> >> [...] > > I'm a bit conflicted about this. Once the LSR is upgraded, it might be >> possible to upload it there, where it will be more accessible to others >> and in a safe place. >> >> On the other hand, the method it uses to incorporate the new grobs is >> problematic, and might even interfere with compiling the LSR (not sure). >> You'll run into problems when you use it with a batch of files (rather >> than compiling files singly): there's bleed-over between sessions, so >> you get errors concerning redefinition of the added properties. >> > > With bar lines, I had a similar issue. Would define-session and > define-session-public stop the bleed-over? When I try to use either of these in a ly file I get "fatal error: define-session used after session start" You can get this engraver to work with multiple files, even with the bleed-over Right now LilyPond exits with a fatal error if you run, say >lilypond one.ly two.ly where both files include "frameEngraver-bars-and-boxes.ily" (which is the file linked to earlier in the thread which contains the definitions) It will work if you change ly:error to ly:warning here: #(define (define-grob-property symbol type? description) (if (not (equal? (object-property symbol 'backend-doc) #f)) (ly:error (_ "symbol ~S redefined") symbol)) (set-object-property! symbol 'backend-type? type?) (set-object-property! symbol 'backend-doc description) symbol) > >> This is really the only way there is to add a new grob now from an ly >> file, though. My motivation in using this method was convenience. >> There's no need (yet) to work in a development environment, and it's >> easy for others to try it out and offer suggestions without needing to >> apply patches. Once it's in a usable state, I would move the various >> parts into their rightful places: the grob definitions into >> define-grobs.scm, for example. (Bleed-over problem solved.) >> >> Honestly, I'd love for this to make it into the code base someday. >> > > Does it make sense to create a patch for it together with a small > paragraph describing the limitations? Once the stuff is 'official', > it is easier for someone else to enhance it. > Yes, this is the rational course... My inclination would be to strip the barline stuff out, work through the remaining code a bit more, and then submit it. This would be better than adding it to the LSR--at least before there is some viable mechanism for creating user-defined grobs. --David
_______________________________________________ lilypond-user mailing list [email protected] https://lists.gnu.org/mailman/listinfo/lilypond-user
