Han-Wen Nienhuys <hanw...@gmail.com> writes:
> On Wed, Sep 30, 2020 at 10:11 PM Han-Wen Nienhuys <hanw...@gmail.com> wrote:
>
>>
>>
>> On Wed, Sep 30, 2020 at 8:05 PM Werner LEMBERG <w...@gnu.org> wrote:
>>
>>>
>>> [git 9c3803fba4960b4afa63baeb50201a0cfa48f8f1]
>>>
>>> I've just built the whole documentation, and I get a strange string
>>> replacement in Appendix A of the NR (from file
>>> `markup-list-commands.texi`), see attached image.
>>>
>> As far as I remember, this didn't happen previously. Is it possible
>>> that this code from `input.itely`
>>>
>>> \paper {
>>> #(add-text-replacements!
>>> '(("100" . "hundred")
>>> ("dpi" . "dots per inch")))
>>> }
>>>
>>> changes the state of lilypond while lilypond-book now processes more
>>> files in one run?
>>>
>>
>> Yes, very likely. See commit 9f16e2962ac71e6a30526012e314d55cec6b7e01.
>>
>> For some reason the check for replacement_cache_alist_key_ is not
>> working as intended.
>>
>
> It looks like the C++ code is working as intended, but
>
> #(define (add-text-replacements! alist)
> (set! text-font-defaults
> (assoc-set! text-font-defaults 'replacement-alist
> (cdaar
> (internal-add-text-replacements (list
> text-font-defaults) alist)))))
>
> modifies text-font-defaults in-place. It looks like the definition being
> changed is the default paper setting, which is shared across files.
assoc-set! on a grob property is not just playing fast and loose across
files but breaks in-file consistency completely as well.
> what was the last version in which this was seen working as expected?
Probably never did but people got lucky.
--
David Kastrup
