On 2016/08/21 16:23:57, mark_opus11.net wrote:
On 2016/08/21 16:22:14, http://mark_opus11.net wrote: > Group lower-level contexts
This introduces a `VerticalAxisGroup.keep-alive-group' property
which can be set to a symbol to associate a subset of contexts
under the control of the same Keep_alive_together_engraver.
This group can further be set to operate only up to a maximum
layer level with the `keep-alive-group-layer' property.
Well, this doesn't seem to do more than the removal-friends/removal-foes proposal (or does it?) and complicates things thoroughly. So let me suggest yet-another-proposal that might require less intricate planning (and the intricate planning aspect was the thing speaking against removal-friends/removal-foes and, to be realistic, already against the currently implemented code which nobody who has a need for it would seem to actually understand well enough to actually use). We create a new context, say RemovalGroup. It has no engravers apart from the Keep_alive_together_engraver. And the Keep_alive_together_engraver does not descend into contexts already having a Keep_alive_together_engraver, instead letting _that_ Keep_alive_together_engraver make its decisions and, uh, consider itself alive if any of its subcontexts is alive? That way its layer number could be assigned independently from the layer numbers of its subcontexts, making it possible not to have to keep a global tally of subgroups but rather use group numbers fresh at each layer. Which would greatly facilitate providing context mods for assigning all the layer numbers and stuff as they would not need to take into account lower or higher groupings. This would sound _almost_ as powerful as your plan and considerably simpler in use. The downside is that if you wanted to have a group with non-contiguous elements, you'd have to put them contiguous into the source and juggle with alignBelowContext and alignAboveContext for rearranging them. But is that a common use case? I hope not, but I might be overlooking something in the context of lyrics. https://codereview.appspot.com/308910043/ _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
