Re: The fate of override/revert/applyOutput

[Han-Wen Nienhuys]

Erik Sandberg schreef:
> 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 {...} >>)

I agree with (2) being better than (1), but I don't see where engravers 
come into play. Hypothetically, it could be possible that a future MIDI 
backend also supports \override and \revert.  Shouldn't this happen in 
the Translator class rather than Engraver?

Is there any practical advantage of changing the current situation to 
(1) or (2) ?


--

Han-Wen Nienhuys - address@hidden - http://www.xs4all.nl/~hanwen

LilyPond Software Design
 -- Code for Music Notation
http://www.lilypond-design.com