Re: Adds outside-staff-interface and outside-staff-axis-group-interface (issue 37950044)

[Mike Solomon]

On Dec 16, 2013, at 12:07 PM, address@hidden wrote:

> On 2013/12/16 09:58:40, mike7 wrote:
>> On Dec 16, 2013, at 11:45 AM, mailto:address@hidden 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