Am So., 13. Nov. 2022 um 15:43 Uhr schrieb Jean Abou Samra <j...@abou-samra.fr>:
>
> Le 13/11/2022 à 14:41, Thomas Morley a écrit :
> > Hi,
> >
> > please consider below (originally for 2.20. _not_ converted):
> >
> > \version "2.23.80"
> >
> > \header {
> > myTitle = "myTitle"
> > myOtherTitle = \markup { \italic \fromproperty #'header:myTitle }
> > title = $(markup->string myOtherTitle)
> > }
> >
> > \markup { "TEST" }
> >
> > A title is not printed.
> > Though, I'm at loss, am I doing something wrongly or is it a bug
> > (\fromproperty has an `as-string'-setting) or _should_ it not work?
>
>
>
>
> This is working as expected. \fromproperty is not different from
> other markup commands. If you try #(display myOtherTitle), you will
> see that myTitle has not been replaced with its value at the time of
> creation of the markup. It is only when the markup is interpreted
> that the definition of the \fromproperty command looks up
> the value of myTitle, and it does so in the props argument
> passed to interpret-markup in the call (interpret-markup layout props mkup).
> When the \header title is implicitly interpreted by LilyPond,
> this is done with a props argument reflecting the header fields,
> as you can see from
>
> \version "2.23.80"
>
> \header {
> foo = "foo value"
> bar = "bar value"
> title = \markup $(markup-lambda (layout props) ()
> ((@ (ice-9 pretty-print) pretty-print) props)
> empty-stencil)
> }
>
> \markup Test
>
>
> The way you are calling markup->string, it does not have this information
> at hand. You need to provide it with
>
>
> \version "2.23.80"
>
> \header {
> myTitle = "myTitle"
> myOtherTitle = \markup { \italic \fromproperty #'header:myTitle }
> title = $(markup->string myOtherTitle #:props
> (headers-property-alist-chain (list (current-module))))
> }
>
> \markup { "TEST" }
>
>
>
> > tl;dr
> > In a private mail the user wondered why running convert-ly over old
> > code containing `markup->string' results in such a complex insertion:
> > 2.20.0 code:
> > title = $(markup->string myOtherTitle)
> > becomes with 2.23.80:
> > title = $(
> > (lambda* (m #:optional headers)
> > (if headers
> > (markup->string m #:props (headers-property-alist-chain headers))
> > (markup->string m)))
> > myOtherTitle)
> >
> > Alas, it doesn't work with the initial code above, still no title.
> >
> > Thus, if it does not work either way, do we need the complex result of
> > convert-ly at all?
>
>
>
>
> But your example code
>
> \header {
> myTitle = "myTitle"
> myOtherTitle = \markup { \italic \fromproperty #'header:myTitle }
> title = $(markup->string myOtherTitle)
> }
>
> \markup { "TEST" }
>
>
> did not work originally in 2.20, did it? I can't test that version on
> my machine (Pango throws an assertion error), but I confirm that in
> 2.22 it does not work. That is as expected, for exactly the same
> reason as above. It does work with
>
> \version "2.22.2"
>
> \header {
> myTitle = "myTitle"
> myOtherTitle = \markup { \italic \fromproperty #'header:myTitle }
> title = $(markup->string myOtherTitle (list (current-module)))
> }
>
> \markup { "TEST" }
>
>
>
> In 2.22, the second optional argument to markup->string was a list
> of header modules. In 2.23, there are two optional keyword arguments,
> #:layout and #:props, and the equivalent of the previous headers
> argument is achieved using headers-property-alist-chain for #:props.
> The convert-ly replacement is a way to cater for that change of
> signature. Admittedly, it is a bit complex, but the alternative would have
> been a NOT_SMART, and I'm not sure that would have been better...
>
> Jean
>
>
Thanks for your detailed explanations.
Nevertheless, _if_ the old code is just (markup->string
<whatever-markup>), would it be possible to leave it untouched while
running convert-ly? After all it continues to work with 2.23. in this
simple manor, only inserting a more complex expression, if the old
code already has an optional argument?
Can't check myself, my python is as non-existent as my C++ ...
Cheers,
Harm
