Re: input/regression/multi-measure-rest-reminder: a demo of user-defined grobs (issue 557380044 by address@hidden)

[dak]

On 2020/02/17 10:01:29, hanwenn wrote:
>
https://codereview.appspot.com/557380044/diff/569320045/input/regression/multi-measure-rest-reminder.ly
> File input/regression/multi-measure-rest-reminder.ly (right):
> 
>
https://codereview.appspot.com/557380044/diff/569320045/input/regression/multi-measure-rest-reminder.ly#newcode26
> input/regression/multi-measure-rest-reminder.ly:26:
#(set-object-property! 
> 'MultiMeasureRestReminder 'translation-type? ly:grob-properties?)
> On 2020/02/16 13:45:30, thomasmorley651 wrote:
> > To make further overrides possible, add:
> > #(set-object-property! 'MultiMeasureRestReminder 'is-grob? #t)
> > 
> > Would solve the issue in my recent comment
> 
> Feel free to send a change!
> 
> I don't understand why we need is-grob? if the symbol is already
marked with
> translation-type? == ly:grob-properties?  
> 
> David?

Comparatively unrelated things.  At any rate, "the symbol is marked" is
historical baggage and we should instead of using "object-properties"
use an explicit weak hashtable for such things since that would make it
possible to _reset_ the hashtable between user files and thus make sure
that user-defined properties don't bleed from one file to the next.  I
just haven't got around to doing this change yet which will break all
user-created grobs (and some other things implemented in the same
manner) and provide a more official way of extension.

At any rate, is-grob? is the way of checking that something is a grob
name syntactically.  translation-type?, in contrast, is the type of the
context property storing the current grob definition.  Historically,
this was an alist I think, and mixing \set and \override on the same
property consequently could cause fascinating crashes.

Using the alist directly did not allow for reliably overriding and
reverting nested context properties.  People patched around that area
for years, further obfuscating the logical impossibility of getting this
done correctly and getting the errors to become more obscure and trigger
in different circumstances.  So at one point of time, I introduced the
ly:grob-properties? data structure tracking nested overrides separately
and "cooking" the resulting alist only on an as-needed base.  That it is
needed for nothing else is not inherently related to it being tied to a
named grob.

https://codereview.appspot.com/557380044/