The fate of override/revert/applyOutput

[Erik Sandberg]

Hi,

With music streams, \set and \override are today similar: Both send a stream 
event directly to the affected context, and the actual override is carried 
out by a hard-coded listener.

There is however one important difference: \override is back-end specific, and 
carried out by an engraver group, while \set is handled by the context 
itself. \override thereby has more in common with applyOutput than with \set, 
so I feel that the implementations of \override and \applyOutput should be 
more similar as well.

I can see two ways to go:
1. Make \override use an \applyOutput-like implementation: Generate music 
events for override/revert, and create a grob-property-engraver, which hears 
override/revert events and applies them.
2. Make \applyOutput send the event directly to a non-bottom context, without 
using report_event. A new ContextSpeccedEvent music type could be created for 
this, and the output-property-engraver would possibly be hard-coded into 
engraver-group.cc.

I like (2) better, because I don't like how applyOutput events bounce on 
bottom context, and because in (1), new context will be created implicitly 
sometimes (e.g., an unwanted extra staff will be created in \new Score 
<<\override Score.Foo #'bar = #baz \new Staff {...} >>)

Besides, the only reason I can see for sending all events to bottom contexts, 
is that it allows implicit context creation; since context creation really 
the job of music iterators, it shouldn't affect the design of music streams.

It will take some time before I'll make this change, but the decision is a 
philosophical one that will affect some design decisions on the way.

-- 
Erik