Re: can't seem to apply tweaks on tweaks

[David Kastrup]

Kieren MacMillan <address@hidden> writes:

> Hello all,
>
> I don’t quite understand when a tweak will apply and when it won’t…
>
> For example, I have an ottavation function for “one-off” octave pops:
>
> octU_single = {
>   \once \override Staff.OttavaBracket.stencil = #ly:line-spanner::print
>   \once \override Staff.OttavaBracket.bound-details =
>     #`((left . ((X . -1) (Y . 0) (padding . -0.5) (stencil-align-dir-y . 
> ,0.85)))
>        (right . ((X . 2) (Y . 0) (padding . -1.5) (text . 
> ,(make-draw-line-markup (cons 0 -1))))))
>   \once \override Staff.OttavaBracket.font-shape = #'roman
>   \once \override Staff.OttavaBracket.bound-details.left.text = \eightva
>   \once \override Staff.OttavaBracket.left-bound-info =
>      #ly:line-spanner::calc-left-bound-info-and-text
>   \once \override Staff.OttavaBracket.right-bound-info =
>      #ly:line-spanner::calc-right-bound-info
>   \ottava #1
> }
>
> Once this is applied, if I try to add a tweak later (e.g., changing
> #’shorten-pair, either “inline” [in the content code] or “externally”
> [via the edition-engraver]), it doesn’t seem to apply.*** But I swear
> I’ve had [many many] other situations where I _can_ apply a tweak to a
> previously-tweaked object.

Those aren't tweaks.  They are overrides.  I'll assume that you are
using a fairly recent version of LilyPond (2.19.28 or later).  If you
aren't, stuff will behave differently, in particular less predictably.

I haven't used the edition engraver yet but I'll assume that it works
via overrides rather than tweaks.  Overrides establish defaults for the
creation of grobs, tweaks are applied afterwards.  So an override will
always lose to a tweak.

Within overrides, we have the special cases of \once \override,
\temporary \override, and subproperty overrides.

\temporary \override differs from \override in that \override alone has
"pop-first" semantics and will first execute a \revert before executing
the override, removing any value previously established in this context.

\once \override basically consists of a \temporary \override and a
corresponding \revert at the end of the time step.  These days, \once
\override does its bookkeeping independently from non-\once \override,
so the corresponding \revert will not accidentally attach itself to
anything else.

Subproperty overrides all do independent bookkeeping as well.  If you
override a subproperty override with some more generic property
afterwards, the subproperty override will remain masked until reverting
the more generic property.  Reverts will only match overrides with the
same exact property path.  Anything else may be temporarily masked by
coarser specified overrides but will resurface when the coarser override
gets reverted.

At any rate: that's all theory.  Unless you actually follow up with an
example of what you are actually doing which does not work as expected,
it will be impossible to tell just what you are doing wrong.

-- 
David Kastrup