lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: pure/impure?!?!


From: David Kastrup
Subject: Re: pure/impure?!?!
Date: Fri, 22 May 2015 12:10:05 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux)

Mike Solomon <address@hidden> writes:

> On 21 May 2015, at 11:01, David Kastrup <address@hidden> wrote:
>> 
>> 
>> In the CG I read
>> 
>>    For certain grobs, the @code{Y-extent} is based on the @code{stencil}
>>    property, overriding the stencil property of one of these will
>>    require an additional @code{Y-extent} override with an unpure-pure
>>    container.  When a function overrides a @code{Y-offset} and/or
>>    @code{Y-extent} it is assumed that this will trigger line breaking
>>    calculations too early during compilation.  So the function is not
>>    evaluated at all (usually returning a value of @samp{0} or
>>    @samp{'(0 . 0)}) which can result in collisions.  A @q{pure} function
>>    will not affect properties, objects or grob suicides and therefore will
>>    always have its Y-axis-related evaluated correctly.
>> 
>>    Currently, there are about thirty functions that are already considered
>>    @q{pure} and Unpure-pure containers are a way to set functions not on
>>    this list as @q{pure}.  The @q{pure} function is evaluated @emph{before}
>>    any line-breaking and so the horizontal spacing can be adjusted
>>    @q{in time}.  The @q{unpure} function is then evaluated @emph{after}
>>    line breaking.
>> 
>> This is all very nice.  Except that it is the function calls labelled as
>> *pure* that actually receive start/end values indicating particular
>> breakpoints of the system that the respective grob is in.  What's the
>> deal with that?
>
> I’d have to dive back into it to remember correctly, but I’m pretty
> sure that these values are ignored.

Ignored or not: those are values indicating breakpoints of the current
system.  They should not even be available for functions evaluated
before any line-breaking.  Or maybe they are called for one of a set of
tentative not-final line breaks, but in that case it would make little
sense to call the post-linebreak (impure?) functions without the actual
linebreak information.

There is some definite piece of the puzzle missing here.

-- 
David Kastrup



reply via email to

[Prev in Thread] Current Thread [Next in Thread]