Updating alists (was: Tenuto marking too close to note)

[Lukas-Fabian Moser]

Hi Jean, (CCing devel because of the stuff below the asterisks)

> > Although this approach manipulates internal data structures of 
> > LilyPond, it has the advantage of dealing with your issue at the root 
> > and not causing side effects for other scripts. Unfortunately, this 
> > approach does not work directly for the (still experimental) LilyPond 
> > builds using Guile2.
>
> Be mindful that assoc-set! is not guaranteed to
> mutate its input. You're not the first one tripped
> up by this API quirk :-)

It's much worse than that: It's not the first time _I've_ been tripped 
up by this (previously it was with sort!). I'll just have to write 100 
copies of

"The exclamation mark in something! does not mean the function is 
guaranteed to make the desired change in-place."

on my wall.

But more seriously: Thanks! And also for advertising ice-9 match - it's 
really a different coding style from the more commonly seen (if pair? 
...) constructs.

* * *

Another question: With the (hopefully) upcoming changes in the 
script-alist structure (using symbols instead of strings as keys), we're 
quite close to being able to simply do

\version "2.23.6"

myScripts = \default-script-alist
myScripts.tenuto.padding = 5

\layout {
  \context {
    \Score
    scriptDefinitions = #myScripts
  }
}

{
  a--
}

(One might also skip defining a new variable and instead change 
default-script-alist directly, but it has to be re-read in a \layout 
block anyway.)

But at the moment, this does not work because the changed key is not 
being replaced in the alist but added at the beginning. If I see things 
correctly, this is the remark about "not coalescing multiple overrides 
of the same property" in nested_property_alist(...) in 
ily/nested-property.cc.

Re-enabling the outcommented branch in that function (taking care to use 
assoc_tail instead of assq_tail and correcting the order of arguments to 
that call) basically works, but there's trouble ahead in the case where 
one does

variable.entry = 15
variable.entry.first = #'i-ve-decided-i-want-a-sublist-after-all

which unfortunately is what happens if one \override's a nested property 
given by a callback (e.g. VerticalAxisGroup.staff-staff-spacing), or worse

variable.entry = #'(some . pair)
variable.entry.first = #'i-ve-decided-i-want-a-sublist-after-all

since an entry that is a pair looks like the beginning of a sublist.

On the other hand, I would expect people who are using

Violin.I = { \someMusic }
Violin.I = { \someNewMusic }

would indeed like to be their first definition to actually be replaced 
(even if using \Violin.I in a score happens to produce only the most 
recent entry).

Thoughts?

Lukas