On 1/19/20, 2:42 PM, "lilypond-devel on behalf of Dan Eble" <lilypond-devel-bounces+c_sorensen=byu....@gnu.org on behalf of d...@faithful.be> wrote:
One of the things in Kieren's intro to the Edition Engraver (EE) that resonated with me was the context paths. His example was something like `singwithbach.along.Voice.B`, which was supposed to refer to something like this: \context Staff = "along" { \context Voice = "B" { ... } } The ability to refer to contexts this way is a great idea, though IMHO it needs some work to reduce ambiguity. But the point I came here to make is this: if an EE using a similar syntax is ever to be a part of LilyPond proper, the syntax ought to be consistently supported for other LilyPond commands that refer to contexts. For example, \context along.Voice.B { ... } \set along.Voice.B.property = #... \change Voice = ChoirStaff.A.Staff.B It would be wise to ask whether there are use cases for any "pronouns" (like `.` and `..` in file paths, and `this` in C++) to make it possible to root a search very specifically. The existence of the `descend-only` music property suggests that there might be. I also think I have a pretty good use case for finding "the closest enclosing context where a given property is defined," but I am not now prepared to elaborate. All of this discussion about including the edition engraver and packages in LilyPond core is exciting to me. I think that if we choose to do so, it should represent a major release for LilyPond, i.e. it should become LilyPond 3.0. And it's possible that we will have some NOT_SMART convert.ly rules connected to the major release; users would potentially need to hand-code changes. Thanks, Carl