Re: [GLISS] - alternative viewpoint

[Keith OHara]

David Kastrup <dak <at> gnu.org> writes:

> "Phil Holmes" <email <at> philholmes.net> writes:
> 
> > What does get me more concerned is how hard
> > it is to find some of the correct ways of tweaking output.  Using
> > voice.SomeValue (or is it Voice.someValue) when it should be
> > staff.Somevalue (or was it Staff.someValue) frequently results in no
> > change to the output.
> 

As they say, "Me too."  This is the reason I gave up on LilyPond, several
times now.

> Yup.  Here is my multi-stage plan for that:

>  b) our C++ engravers announce to the type system (and via that, to the
> documentation) which context properties they read, modify and write.
> There is no reason that this does not also include the Grob descriptions
> which are even now a special case of context property.

>  d) \override xxx is equivalent to \override Bottom.xxx, with Bottom
> being a context without \defaultchild (to be recursively created from
> the current context, if that is not a bottom context, by creating the
> respective defaultchildren in sequence until hitting bottom).  If all
> our engravers had correctly registered the context properties they read,
> \override xxx could instead set the property in the context closest to
> bottom that will actually _look_ at the changed property.
 
These two steps alone will drastically increase usability and the user-base.

> Of course, this is not without drawback either: if there are multiple
> engravers looking at that property at multiple levels 

This 'drawback' is still an improvement relative to the current situation.
         \once\override TimeSignature #'stencil = ##f
If the override has effect only for one staff when we wanted it to affect
a StaffGroup, it is easier to discover the solution than currently, where
the override is ignored entirely.