Re: [GLISS] - alternative viewpoint

[David Kastrup]

Keith OHara <address@hidden> writes:

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

>>  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).

For clarity: the above describes the _current_ situation.

>> 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.

I was more thinking of the situation where multiple _unrelated_
engravers look at the same property for different reasons.  In that case
you likely need to set the property at the outermost level where
somebody is listening.  In contrast, when there are multiple related or
identical engravers listening, the _innermost_ level is quite
appropriate since it is _desired_ that the outer engravers of the same
kind don't get the same information.

There are also override collections like \voiceOne, and not all
overrides might apply in every context they are used in: in that case we
don't want a warning.  So it is not an issue quite as simple as it may
seem at first, but it is definitely on my agenda when I rework the
property system.

Which does not mean that people are free to beat me to it within the
current system.

-- 
David Kastrup