[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Adds outside-staff-interface and outside-staff-axis-group-interface
From: |
Mike Solomon |
Subject: |
Re: Adds outside-staff-interface and outside-staff-axis-group-interface (issue 37950044) |
Date: |
Mon, 16 Dec 2013 12:12:59 +0200 |
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