Re: Odd interaction between ly:grob-property and hairpin

[Jean Abou Samra]

Le 10/02/2022 à 22:57, David Kastrup a écrit :
> Jean Abou Samra <jean@abou-samra.fr> writes:
>
> > Le 10/02/2022 à 15:42, Simon Albrecht a écrit :
> > > Hi Aaron,
> > >
> > > thanks a lot for the help! I knew that these pure vs. impure issues
> > > exist, but I’ve never been able to wrap my head around them and this
> > > is the first time I ever needed to account for them in practice.
> > >
> > > Looking at Extending Manual section 2.8, it seems that Y-offset is
> > > likely to be affected, so that makes sense.
> > >
> > > What I don’t quite get is the meaning of the ‘begin’ and ‘end’
> > > parameters in ly:grob-pure-property, but as long as 0 0 works, I’m
> > > good ;) (and it’s not a topic for the bug list)
> > >
> > > Best, Simon
> >
> >
> > Sorry, I just received this message now so my previous reply didn't
> > account for it (yes, list messages are taking 5 hours to reach
> > recipients sometimes, this was discussed recently on lilypond-user).
> >
> > So, to answer your question, start and end are column ranks.
> > The meaning of the question (ly:grob-pure-property grob start end)
> > is "What will this grob property approximately on the broken
> > piece if this spanner is broken between start and end?"
> Not the way I understand things.  The question is "What will this grob
> property be in a line that starts in column `start` and ends in column
> `end`.  That spanners consist of broken pieces is a different
> complication not specifically related to start/end.



What would be the difference exactly? I don't understand what
you mean.



> > (for items they should be ignored).
> I don't see that.  Even items may have different properties depending on
> start/end.  For example, accidental rules should be taking them into
> account (but don't currently) since accidentals on notes tied over bars
> get repeated after a line break (and then don't need another
> repetition).



I was not talking the ideal design (which I happened to be exactly
working on while receiving this message). Rather I was talking about
the current design, which is that, to my knowledge, all pure functions
ignore start and end when passed an item, and item pure heights are
actively cached independently of start and end because they are
assumed not to depend on them and this saves calculations.

Interval
Item::pure_y_extent (Grob *g, vsize start, vsize end)
{
  if (cached_pure_height_valid_)
    return cached_pure_height_ + pure_relative_y_coordinate (g, start, 
end);
  /* Note: cached_pure_height_ does not notice if start changes, implicitly
     assuming that Items' pure_heights do not depend on 'start' or 'end'.
  */

  cache_pure_height (Grob::pure_y_extent (this, start, end));
  return cached_pure_height_ + pure_relative_y_coordinate (g, start, end);
}



> > They are used in VerticalAxisGroup pure calculations, to estimate how
> > tall a staff will be between two certain points in order to score page
> > breaking configurations.
> Yes, that's more like it.