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/
