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/ _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
