Re: markup->string

[Jean Abou Samra]

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

OpenPGP_signature
Description: OpenPGP digital signature