Mike Solomon <[email protected]> writes: >> On 24 Sep 2015, at 13:18, David Kastrup <[email protected]> wrote: >> >> Han-Wen Nienhuys <[email protected]> writes: >> >>> IIRC, it was introduced to compose offset callbacks, >> >> Oh, it's still being used for that as far as I can tell. Just not from >> Scheme. > > I think before lambdas were widely used they made lots of sense. I > used to like these because they were easier (for me) to debug than > lambda functions, where all heck could break loose on the inside. But > it is true that they are not used much anymore. I’d vote for > depreciating them. > > The pure/unpure stuff has definitely needed reorganising for almost 9 > years now - there must be a better way to do it.
Well, the basic target for me is that whatever needs a start/end column for its decision-making has to ask for it. And when it asks for it, that request is put on record and any resulting value is only considered cached for the respectively recorded preconditions. If some property callback does not ask for start/end column either directly or by reading other grob properties depending on such values, the value is cached as being final. Basically the pure/unpure business should be determined dynamically. Then stuff like an accidental for a tied note at the start of a bar can make the unpure/pure split only when all the preconditions are met and just behave boringly otherwise, having its dimensions and stencil just generated once and then cached. And even when it makes the split, it will only generate one set of values for each start column but not differentiate according to end column. Half-pure, so to say. The end goal has to be that the depency tracking is not the job of the programmer of the basic typesetting code or extending LilyPond with new graphical features becomes too much of a specialist job. Amateur typesetters need to be able to do that without being experienced core programmers, or we have a bottleneck for typesetting knowledge passing into LilyPond. -- David Kastrup _______________________________________________ lilypond-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/lilypond-devel
