Adds outside-staff-interface and outside-staff-axis-group-interface

Adds outside-staff-interface and outside-staff-axis-group-interface

When a property exists in an interface, the property should make sense for
a sensible of grobs that implement that interface.  Otherwise, the property
should be part of a separate interface that applies to a sensibly-sized
group of grobs.

Various properties having to do with outside-staff calculations belong to
grob-interface.  This does not make sense for many grobs (StaffSpacing,
NoteSpacing, SpacingSpanner, StaffSymbol just to name a few).  There is a
limited collection of grobs for which outside-staff properties make sense.
The outside-staff-interface provides a separate interface to be implemented
by these grobs.

The same is true for axis groups that place outside-staff grobs, which form
a limited subset of grobs implementing the axis-group-interface.  Rather than
putting the relevant properties in the axis-group-interface, we move
them to an outside-staff-axis-group-interface.

[dak, 2013-12-16 09:45:34]

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.

[Trevor Daniels, 2013-12-16 09:56:44]

I applaud this!  Properties in an interface which 
were not honoured when processing certain grobs
which purported to implement that interface really
irritated me when trying to write documentation.

Trevor

[mike7, 2013-12-16 09:58:40]

On Dec 16, 2013, at 11:45 AM, dak@gnu.org 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.
 Setting:

NoteSpacing.outside-staff-priority

makes my brain go NaN/0.  I the same way that setting:

NoteSpacing.bracket-flare

makes my brain go NaN/0.  The difference is that the second triggers a
programming error whereas the first doesn’t.

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.

Cheers,
MS

[mike7, 2013-12-16 09:58:55]

On Dec 16, 2013, at 11:56 AM, tdanielsmusic@googlemail.com wrote:

> I applaud this!  Properties in an interface which
> were not honoured when processing certain grobs
> which purported to implement that interface really
> irritated me when trying to write documentation.
> 
> Trevor
> 
> 
> https://codereview.appspot.com/37950044/

Good deal - thanks!

Cheers,
MS

[dak, 2013-12-16 10:07:34]

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

[mike7, 2013-12-16 10:13:14]

On Dec 16, 2013, at 12:07 PM, dak@gnu.org wrote:

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

[MikeSol, 2013-12-16 13:02:33]

Adds outside-staff-interface to ChordName

[MikeSol, 2013-12-21 12:47:59]

Gives outside-staff-interface to several other grobs

[dak, 2013-12-25 22:07:41]

Spacing problems.  Nothing requiring to prolong the review, but should be fixed
before pushing.

https://codereview.appspot.com/37950044/diff/40001/scm/define-grobs.scm
File scm/define-grobs.scm (right):

https://codereview.appspot.com/37950044/diff/40001/scm/define-grobs.scm#newco...
scm/define-grobs.scm:355: outside-staff-axis-group-interface))))))
Don't use tabs in Scheme files.  Incidentally, this whole file only contained a
single tab previous to this patch, and that single tab is
0c849c547 scm/define-grobs.scm     (Mike Solomon       2013-08-27 08:44:23 +0300
 171) 	(cross-staff . ,ly:arpeggio::calc-cross-staff)

It's probably sufficient to run scripts/auxiliar/fixscm.sh on the file before
committing, but it's not clear that this will not affect other lines.

https://codereview.appspot.com/37950044/diff/40001/scm/define-grobs.scm#newco...
scm/define-grobs.scm:1984: slur-interface))))))
Tabs again.

https://codereview.appspot.com/37950044/diff/40001/scm/define-grobs.scm#newco...
scm/define-grobs.scm:2295: outside-staff-axis-group-interface))))))
Tabs again

https://codereview.appspot.com/37950044/diff/40001/scm/define-grobs.scm#newco...
scm/define-grobs.scm:2734: outside-staff-axis-group-interface))))))
More tabs.