Werner LEMBERG <w...@gnu.org> writes:
>>> 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?
A loop?
>>> + // 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.
Can you describe in a short paragraph what constructs are allowed, what
results are expected, and what constructs may be processed but deliver a
warning? That's sort of what defines a feature.
--
David Kastrup
_______________________________________________
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
