[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Lukas-Fabian Moser
Subject: Updating alists (was: Tenuto marking too close to note)
Date: Thu, 30 Dec 2021 12:36:37 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0

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 {
    scriptDefinitions = #myScripts


(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/

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).



reply via email to

[Prev in Thread] Current Thread [Next in Thread]