>> Not sure whether the coding fits lilypond's C++ style, however. > > Seriously? C++ has loops, you don't need goto for that.
What construction do you suggest as a replacement? >> + // One single-moment bracket is allowed. Abbreviating a horizontal >> + // bracket's `START' span-direction with `L' and `STOP' with `R', this >> + // means that we can have >> + // >> + // LLL...LLR >> + // >> + // or >> + // >> + // LRRR...RR >> + // >> + // events attached to a single moment (we don't take care of the order of >> + // `L' and `R' events). >> + >> if (d == STOP) >> { >> pop_count_++; >> - if (pop_count_ > bracket_stack_.size ()) >> + if (pop_count_ > bracket_stack_.size () + 1) > > [...] > >> \include "ColorSpanDef.ily" >> >> \new Staff { >> \override HorizontalBracket.line-thickness = #0 >> \genericSpan #-4 #-2 #-4 #-2 >> \colDarkRed \colLightRed #0 #0 ##f ##f >> <c' d'>2\startGroup\stopGroup >> >> c'4\startGroup\startGroup\stopGroup >> c'4\startGroup\stopGroup\stopGroup >> } >> >> \layout { >> \context { >> \Voice >> \consists "Horizontal_bracket_engraver" >> } >> } > > If the resulting semantics and the allowed and not allowed > constructs cannot be described in a reasonably straightforward > manner with reasonably straightforward code, we should strive for > something more coherent, even if it means a larger effort in coding > at the program (rather than the user) level. Try-it-until-it-works > features are indistinguishable from bugs and could work differently > in future versions. I have no idea what you are talking about. What is not coherent in your opinion? You don't like the c'4\startGroup\stopGroup construction? For me this looks like a quite natural extension (which, I guess, most of us have tried already) – at least for horizontal brackets. If you can improve the code – or even generalize – I would be more than glad. Werner _______________________________________________ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user