Re: Repeat Box

[David Nalesnik]

Marc,

On Thu, Mar 6, 2014 at 8:40 AM, Marc Hohl <address@hidden> 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