Keith OHara <k-ohara5...@oco.net> 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 _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel