On Dec 16, 2013, at 12:07 PM, [email protected] wrote: > On 2013/12/16 09:58:40, mike7 wrote: >> On Dec 16, 2013, at 11:45 AM, mailto:[email protected] wrote: > >> > The summary seems incompatible with >> > <URL:http://music.stackexchange.com/a/14160/8773> >> > >> > Once an interface is required for outside-staffing a grob, the set > of >> > grobs one can use in that manner is hardwired to the "intended" > grobs. > >> This is true. The outside-staff-interface would need to be applied to > every >> grob that could, in theory, be shifted this way. I’d need help in > flagging >> grobs I’ve missed - I’ve gotten everything that uses it in the > regtests, but >> there are others that are not tested. The stackexchange example is > one of >> them. > >> I think the hardwiring is good in that we should avoid letting grobs > implement >> interfaces with properties that could never, in any circumstance, > apply to them. > > [...] > >> As a corollary, if it doesn’t exist already, we may want to create a > mechanism >> to add or subtract interfaces from grobs at runtime. > > As a corollary, if it doesn't exist already, we may want to create a > mechanism to add interfaces to grobs with properties that could never, > in any circumstance, apply to them? > > That does not look like a corollary. More like an antithesis. >
never-in-any-circumstance is too strong: downgraded to only-in-circumstances-that-developers-can’t-anticipate. Meaning that if users esteem that NoteSpacing needs bracket-flare, there should be a mechanism in place to add an interface implementing that. However, in LilyPond proper, we should not make that a default because we as a community agree that NoteSpacings do not have bracket-flair. Cheers, MS _______________________________________________ lilypond-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/lilypond-devel
