[Lilypond-auto] [LilyIssues-auto] [testlilyissues:issues] Re: #4973 Group contexts in the Keep_alive_together_engraver

[Auto mailings of changes to Lily Issues]

That is not my recollection of the discussion.

Obviously, since our approaches have diverged a bit more. And it's not always easy for me to tell just what amount of the discussion happened only in my head: sometimes I come to conclusions after arguing back and forth with myself and after a while it feels like the argument had been made in public when all that appeared there was the conclusion without much of a rationale.

Now here is the essence of what I was brooding over: my original remove-layer feature was coded more or less on-demand, implemented by providing context properties, and those properties and the underlying mechanism were documented and explained.

Half a year later, several power users including those requesting the feature were totally baffled that those properties could be used to do just what they needed.

That was the "simple" request and feature not supporting nested divisi structures.

So my basic conclusion about this feature as implemented by myself is that it is a copout feature: its only usefulness is to myself since I can then claim "but I already solved that problem". It's not user accessible.

Now obviously a scheme-accessible mechanism for implementing a user-accessible feature is better than nothing.

But I think the next thing we need to do is creating an actual user interface for the use cases this mechanism has been created for. One where the user tells LilyPond in musical rather than in programming terms what his music is. This user interface needs not cover every use case the underlying mechanism can be made to cater for: if we forgot an application, one can always add it afterwards, per LSR or in LilyPond proper.

Your patches here try casting the terms of the mechanism and the properties in the language of the musical application in order to make them more accessible. But when that did not even work convincingly for the simple original remove-layer, I don't think it will fly for the complex ones.

So I think we should separate what we want to do in musical terms (and create scheme functions and/or container contexts providing all of the requisite folderol behind the scenes) and how it is implemented, and make the former work in straightforward music terms and the latter work in straightforward programming terms.

I don't think that we can expect to make one interface that's both easy to use and easy to understand (regarding its innermost workings), given the previous experience with the simple version. And this is, as far as my gut feeling goes, exactly what this patch is aiming to do, and I don't see that it makes the ends meet. So I prefer getting the ends done well separately, one end for the user, one for the programmers.

So I'd like us to figure out how to specify the simple case in a simple manner best (without worrying about the implementation), and then think about how to best generalize this in a manner for multiple divisi situations, if we can in a manner that is not any more complicate but just a generalization of the simple way that can be nested. And only then look for the simplest set of properties and engravers that we would need for implementing this in a reasonably straightforward manner (without reverting to trick programming).

---

[issues:#4973] Group contexts in the Keep_alive_together_engraver

Status: Started
Created: Fri Sep 16, 2016 06:16 PM UTC by mkdev
Last Updated: Sun Sep 25, 2016 10:45 AM UTC
Owner: mkdev

Group contexts in the Keep_alive_together_engraver

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 operates only up to the highestremove-layer` level of its
members.

http://codereview.appspot.com/310230043

---

Sent from sourceforge.net because address@hidden is subscribed to https://sourceforge.net/p/testlilyissues/issues/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/testlilyissues/admin/issues/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.

------------------------------------------------------------------------------

_______________________________________________
Testlilyissues-auto mailing list
address@hidden
https://lists.sourceforge.net/lists/listinfo/testlilyissues-auto