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

[dak]

On 2016/08/02 13:55:56, mark_opus11.net wrote:
> On 2016/08/02 11:45:28, dak wrote:
> > 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.

I'd have those extra lists default to #f, implying the numerical
behavior.  When they are lists (including '()) then they'll behave
strictly as lists.

> > 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?

remove-friends and remove-foes ?

Maybe this needs to be removal-friends, removal-foes, and removal-layer
?  "remove" as a category name for "removal-related" in compound names
just scans badly.

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