Re: Keep a staff alive with multiple layers (issue 308910043 by address@hidden)

[mark . opus11]

On 2016/08/02 11:45:28, dak wrote:
> I've taken a look at the code and it does not appear like there is a
danger
> for infinite loops: the checks for suicide relying on other axis
groups are
> not called recursively.  The only real danger we are dealing with here
is
> inefficiency, and particularly undefined behavior since a context may
decide
> to commit suicide based on the status of a context which already
suicided on
> the expectation of the first context staying alive.  If the order of
checks in
> such a situation are reversed, the outcome may be different.  Should
we
> declare this "somebody else's problem"?

As far as I can tell, the iteration in
Keep_alive_together_engraver::finalize
and Hara_kiri_group_spanner::request_suicide is always from top to
bottom (as
presented in the \score block) and so should be predictable in that the
first
encountered context will decide first. But I've not been able to
construct a
situation where anything unintended happens.

> At the low level, dependencies are decided by make-dead-when and
> keep-alive-with properties (containing vertical axis groups) which are
> populated based on the remove-layer setting.  If we want to provide
the
> underlying flexibility, we'd likely need a remove-layer property and
_two_
> properties carrying lists of layer numbers.  Or _one_ property with a
list
> where the _sign_ of the layers indicates friend or foe.

> However, using the sign will _fix_ layer numbers to be numbers.  When
going
> general like that, going via key-list? seems plausible, and then we'll
require
> two additional lists anyway since a symbol cannot provide a sign.

So this would essentially be two user settable properties which provide
indirect
access to the make-dead-when and keep-alive-with internal properties.
With the
additional intervening logic of numerical ordering in the engraver
taking care
of purely numerical cases.

> So would it make sense to provide the full hog that the low-level
decision
> engine supports?  Basically, we want the kind of user interface where
people
> need to think the least but still can do everything they want to.

Does this make the multi-level divisi situation that Abraham raised any
easier?
http://lists.gnu.org/archive/html/lilypond-devel/2016-07/msg00227.html
Probably a bit.

New property names: "keep-alive-with-layers", "make-dead-with-layers"?
Or
perhaps rename the internal properties to those and reclaim the shorter
names
for the user properties?

https://codereview.appspot.com/308910043/