Re: Reimplement forced partcombine decisions via context properties (issue 144600043 by address@hidden)

[dak]

On 2014/10/28 07:00:33, Keith wrote:

> In order to make a \once\partcombineApart work like most other
\once\override
> commands, you would have to do something like delay the forced
part-combine
> decisions until the real engraving, write a real Part_combine_engraver
that
> lives in the Staff, and store the forced state in properties in that
Staff
> (maybe renaming what is currently called Part_combine_engraver to
> Part_combine_text_engraver).

I don't like the design of the current partcombiner.  In particular it
seems strange to use an artificial output definition rather than one
derived from the current one.  But that's a larger and separate issue.

> Unless you want add a third iterator call, and send a parallel music
constructin
> of m1 and m2 into that, for the forced-part-combine commands, handling
the
> commands as properties at this stage is awkward and cannot give as
nice a
> behavior as Reinhold's original code.

For some definition of "nice".

At any rate, things would be considerably more straightforward if one
caught the after-timestep actions of \once ... separately in a music
list instead of grouping them with the next event.  But that would mean
changing the output of recording-group-emulate or what it's called.

https://codereview.appspot.com/144600043/