Re: LaissezVibrerTie and LaissezVibrerTieColumn

[David Kastrup]

Thomas Morley <address@hidden> writes:

> So how to proceed with 5220?
> I'm confident I could adapt your change once it is in master

More like "use it".  I don't think you need to do anything with it.

> and maybe even prepare the engravers so that a follow up could
> implement the idea of https://codereview.appspot.com/335910043/#msg2
> easily, though I'm not able to realize this idea myself.

The main thing is listing just what the differences between the two
engravers were.  All those need to be made overridable in whatever will
serve as the base class.

> Btw, why do we redefine LaissezVibrerTie-stencil in output-lib.scm?
> The comment says:
>
> ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
> ;;  laissez-vibrer tie
> ;;
> ;;  needed so we can make laissez-vibrer a pure print
> ;;
> (define-public (laissez-vibrer::print grob)
>   (ly:tie::print grob))
>
> Is this (still) true or could it be deleted (and define-grobs.scm
> adjusted, ofcourse)?

This looks like a remnant of
commit 55d4389e74f830d759176867dae44ed0400c3b68
Author: Carl Sorensen <address@hidden>
Date:   Fri May 14 19:51:57 2010 -0600

    Fix 881, with Neil's suggestion
    
    Make laisser-vibrez::print a pure function
    
    Add regression test for issue 881

before

commit 74e4d219b24ec6d6f28d663c0285418e6c8e122e
Author: Mike Solomon <address@hidden>
Date:   Tue Mar 5 21:03:55 2013 +0100

    Uses only unpure-pure containers to articulate unpure-pure relationships 
(issue 3199)
    
    Previously, LilyPond used several different lists in define-grobs.scm
    to define relationships between unpure and pure functions.  This patch
    eliminates these lists, using unpure-pure containers to articulate
    these relationships.
    
    The modifications required to implement this change are described below:
    
    -) axis-group-interface.cc
    A Scheme function is no longer needed to determine pure relevant grobs.
    All grobs can have their Y-extents meaningfully pure-evaluated now. The
    worst-case scenario is that they evaluate to false. Dead grobs, on the
    other hand, are never pure relevant. The calls to is_live are the only
    holdovers from the old pure-relevant? scheme function.
    
    -) grob-closure.cc
    We allow unpure-pure containers in simple closures.
    
    -) grob-property.cc
    call_pure_function no longer looks up a Scheme module. Because there are
    no hard-coded lists in Scheme any more, the function is smaller and
    writing it in C++ gets slight efficiency gains.
    
    -) grob.cc
    pure_stencil_height used to be a Scheme function in define-grobs.scm.
    Because it is much simpler (it no longer makes references to lists defined
    in Scheme), it can be implemented in C++.
    
    -) pure-from-neighbor-engraver.cc
    Similar to axis-group-interface.cc, the pure-relevant distinction is
    no longer important.
    
    -) side-position-interface.cc
    In order to avoid issues with alterBroken, we only check pure properties
    before line breaking.
    
    -) simple-closure.cc
    Simple closures were incorrectly evaluated when containing unpure-pure
    containers. This rectifies that.
    
    -) stencil-integral.cc
    Several pure equivalent functions needed to be written for skylines.
    
    -) define-grobs.scm
    Multiple overrides must be changed to unpure-pure containers. Previous
    hard-coded lists are all deleted and several functions moved to C++ (see
    above).
    
    -) output-lib.scm
    Several common unpure-pure containers used in define-grobs.scm are
    defined here. Several functions from define-grobs.scm pertaining to
    grob offsets are moved to this file.


So I think that at the current point of time, this can likely be
retired.  Or at least, the definition can be simplified to

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;  laissez-vibrer tie
;;
;;  Backward compatibility alias
;;
(define-public laissez-vibrer::print ly:tie::print)


-- 
David Kastrup