Re: Issue 3518: Support temporary divisi staves (issue 131970043 by address@hidden)

[dak]

Reviewers: lemzwerg,

Message:
On 2014/08/20 14:48:41, lemzwerg wrote:
> LGTM.  Very nice!  I guess it makes sense to actually provide
`\boring' and
> `\tricky' with better names...

For a real use case/interface (which would also warrant ending in a
snippet and/or the documentation), \boring and \tricky in the current
form would not really work well: the whole point of a divisi passage is
to disentangle a situation that is too hard to show properly in a single
staff.  But that means that we want the passages now placed between
\tricky and \boring to be replaced by spacer rests or similar in the
single staff.  Otherwise we'll get NoteColumn collision warnings and
similar for the tricky passages and, worse, have the overcrowded tricky
single-staff passages (which will not appear on paper) determine the
horizontal spacing in the divisi passages.  Of course, some interference
of ultimately disappearing staves cannot be avoided, but at least those
passages where the complexity is known to _demand_ the divisi staves,
cramming the material into a non-divisi phantom staff should not be
allowed to determine warnings and spacing.

Description:
Issue 3518: Support temporary divisi staves

This provides the low-level support for temporary divisi staves by
adding a `VerticalAxisGroup.remove-layer' property of type integer that
interacts with the "Keep_alive_together_engraver": when set to a numeric
value, staves with the same numeric value are kept alive together as one
group.  Of several such groups with live staves, only the one with the
lowest common numeric `remove-layer' is retained.


Also contains commits:

Regtest for VerticalAxisGroup.remove-layer (divisi staves)

Reformat define-grob-properties.scm to avoid column 0 parens in strings


This is actually a more low-level interface than the discussion in the
issue is mostly about.  Since the provided mechanisms are considerably
simpler and more flexible than envisioned in the discussion, it makes
sense to let people integrate this into their existing
frameworks/workflows without prescribing particular wrappers at this
point of time.

Please review this at https://codereview.appspot.com/131970043/

Affected files (+112, -16 lines):
  A input/regression/divisi-staves.ly
  M lily/hara-kiri-group-spanner.cc
  M lily/keep-alive-together-engraver.cc
  M scm/define-grob-properties.scm