Re: strange replacement 100 → hundred in NR

[David Kastrup]

Han-Wen Nienhuys <hanwenn@gmail.com> writes:

> On Wed, Sep 30, 2020 at 10:11 PM Han-Wen Nienhuys <hanwenn@gmail.com> wrote:
>
>>
>>
>> On Wed, Sep 30, 2020 at 8:05 PM Werner LEMBERG <wl@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