Le 15/11/2022 à 15:18, David Kastrup a écrit :
Conversion rules can look at the number of arguments and only revert to
a generic replacement when the number of arguments cannot be determined
(like when the arguments are too complex for the patterns, or
markup-string is not used as a call but as a
On Tue, Nov 15, 2022 at 02:49:55PM +0100, Jean Abou Samra wrote:
> Le 15/11/2022 à 14:43, David Kastrup a écrit :
> > If it's "mundane", why would the conversion result in a complex
> > replacement?
>
> Have you looked at the replacement?
>
> It is
>
> (lambda* (m #:optional headers)
> (if hea
Jean Abou Samra writes:
> Le 15/11/2022 à 14:43, David Kastrup a écrit :
>> If it's "mundane", why would the conversion result in a complex
>> replacement?
>
>
>
> Have you looked at the replacement?
>
> It is
>
> (lambda* (m #:optional headers)
> (if headers
> (markup->string m #:props (
Le 15/11/2022 à 14:43, David Kastrup a écrit :
If it's "mundane", why would the conversion result in a complex
replacement?
Have you looked at the replacement?
It is
(lambda* (m #:optional headers)
(if headers
(markup->string m #:props (headers-property-alist-chain headers))
(
Jean Abou Samra writes:
> Le 15/11/2022 à 14:17, David Kastrup a écrit :
>> Alternatively, providing something approaching the previous behavior
>> under a different name, assuming that this functionality has at least
>> some motivation or possibility to continue existing.
>
>
>
> It's not a beha
Le 15/11/2022 à 14:17, David Kastrup a écrit :
Alternatively, providing something approaching the previous behavior
under a different name, assuming that this functionality has at least
some motivation or possibility to continue existing.
It's not a behavior change, just a mundane calling con
Jean Abou Samra writes:
> Le 15/11/2022 à 00:56, Jean Abou Samra a écrit :
>>> Nevertheless the insertion done by convert-ly is not nice, imho. As a
>>> mere user I'd think some bug happened.
>> In that case, NOT_SMART is the way to go (i.e., not changing
> anything but just printing “Not smart e
Le 15/11/2022 à 00:56, Jean Abou Samra a écrit :
Nevertheless the insertion done by convert-ly is not nice, imho. As a
mere user I'd think some bug happened.
In that case, NOT_SMART is the way to go (i.e., not changing anything but just
printing “Not smart enough to convert…”).
https://gitl
> Le 15 nov. 2022 à 00:48, Thomas Morley a écrit :
>
> Well, I have to admit I can't follow.
> In my understanding the old markup->string has one or more arguments,
> the first must be of type markup.
> Obviously my understanding is not entirely correct.
It is correct. The problem is that pa
Am So., 13. Nov. 2022 um 16:30 Uhr schrieb Jean Abou Samra :
>
>
>
> > Le 13 nov. 2022 à 16:22, Thomas Morley a écrit :
> >
> > Nevertheless, _if_ the old code is just (markup->string
> > ), would it be possible to leave it untouched while
> > running convert-ly? After all it continues to work wit
> Le 13 nov. 2022 à 16:22, Thomas Morley a écrit :
>
> Nevertheless, _if_ the old code is just (markup->string
> ), 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,
Am So., 13. Nov. 2022 um 15:43 Uhr schrieb 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 { \ital
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
13 matches
Mail list logo