Werner LEMBERG <w...@gnu.org> writes:
>>> if (d == STOP)
>>> {
>>> pop_count_++;
>>> - if (pop_count_ > bracket_stack_.size ())
>>> +
>>> + // Since N `L' events create N HorizontalBracket grobs we need (at
>>> + // most) N `R' events to finish them. However, at this particular
>>> + // moment, a single-moment horizontal bracket might be created also;
>>> + // this takes another `L' event (which might not have caused a new
>>> + // element on `bracket_stack' yet) and its corresponding `R' event.
>>> + if (pop_count_ > bracket_stack_.size () + 1)
>>> ev->origin ()->warning (_ ("do not have that many brackets"));
>>> }
>>
>> "which might not have caused a new element"? That sounds like this
>> may or may not suppress an actually warranted warning.
>>
>> Correct?
>
> Right, thanks for noticing. I've fixed this – to a certain extent,
> see comments in the attached new version of the patch.
>
> If someone is going to rewrite the algorithm, the order of events
> should be obeyed.
For simultaneous events, LilyPond has no order. That's why one needs to
have one phase for recording events and another for doing something
based on them.
There is a very tricky exception in order to distinguish
[Some override] \grace { ...
from
\grace { [Some override] ...
since \grace itself overrides a number of properties (mostly sizes) and
the order needs to be heeded. The grace iterator creates special events
for that purpose.
Maybe the infamous issue 34 could be tackled as part of that mechanism?
Not sure about that.
--
David Kastrup
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
