On Mon, Mar 21, 2011 at 11:18 PM, Keith OHara <k-ohara5...@oco.net> wrote:
> On Mon, 21 Mar 2011 23:06:12 -0700, Joe Neeman <joenee...@gmail.com>
> wrote:
>
>
>> Unfortunately, if I protect the assignment to the property with an if
>>> (!pure), I am letting the page-breaking planning rely on the
>>> user-requested
>>> affinities, and then changing them for the page-layout phase. The
>>> boolean
>>> 'pure' asks explicitly that we keep the state unchanged, but there was
>>> always an implicit expectation that certain properties are unchanging.
>>>
>>
>>
>> I don't quite understand this comment. The only effect of set_property is
>> to
>> prevent the warning from being triggered more than once per system. In
>> fact,
>> the layout would be completely unchanged even if you removed the whole
>> if(after_affinity > before_affinity) block. So why does it matter if we
>> condition set_property on something?
>>
>> In a typical case, the effect is after->set_property("staff-affinity",
> DOWN)
> and then when get_spacing_spec is called to determine the next spring,
> working through the (non)staffs in the system, it will look up the staff
> affinity we just set for use as before_affinity, thus the next spring is
> changed. The code in the if(after_affinity>before_affinity) block does
> change the output for the example at the head of issue 1555.
>
Ok, good point. In that case, a better way to avoid too many warnings might
be just to add a static bool to check if a warning has already been issued.
Joe
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
