Re: pure/impure?!?!

[Mike Solomon]

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.

Cheers,
MS