Re: Colored box behind a single note

[David Kastrup]

Werner LEMBERG <address@hidden> 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