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
s
>
> (lambda* (m #:optional headers)
> (if headers
> (markup->string m #:props (headers-property-alist-chain headers))
> (markup->string m))
I agree with others' assessment that this doesn't "look" good: it's
taking logic that, in a perfect world, would be interna
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)
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-
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
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
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
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…”).
> 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
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
> 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 mo
{
> >myTitle = "myTitle"
> >myOtherTitle = \markup { \italic \fromproperty #'header:myTitle }
> >title = $(markup->string myOtherTitle)
> > }
> >
> > \markup { "TEST" }
> >
> > A title is not printed.
> >
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 m
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
Hi Paul,
thanks for review
https://codereview.appspot.com/34743/diff/40001/scm/markup.scm
File scm/markup.scm (right):
https://codereview.appspot.com/34743/diff/40001/scm/markup.scm#newcode141
scm/markup.scm:141: ;; The string is split at line-breaks, emty strings
removed and finally
On 2018/11/11 15:08:57, thomasmorley651 wrote:
simplify, catch string-markups
patch-set 3 reflects my musing in comment #5
https://codereview.appspot.com/34743/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
Hi Harm, I took a quick look and it LGTM at a quick read. I have a
couple nit-level suggestions.
-Paul
https://codereview.appspot.com/34743/diff/40001/scm/markup.scm
File scm/markup.scm (right):
https://codereview.appspot.com/34743/diff/40001/scm/markup.scm#newcode141
On 2018/11/11 11:07:35, dak wrote:
On 2018/11/11 10:57:31, thomasmorley651 wrote:
> 'all-relevant-markup-commands' tries to get all
markup-(list-)commands where
> 'markup->string' may return reasonable output.
I have to get used to the thought of not having the monopoly on go
about stuff I know nothing about.
'all-relevant-markup-commands' tries to get all markup-(list-)commands
where
'markup->string' may return reasonable output.
I have to get used to the thought of not having the monopoly on good
ideas. That's all. I had assumed that you work with large lis
produce their last argument? That leaves fewer
commands
to cater for and would also make some user-defined commands work
reasonably
well.
I think I do not fully understand what you mean.
'all-relevant-markup-commands' tries to get all markup-(list-)commands
where 'markup->string' may ret
I wonder whether it might be reasonable to just have all markup commands
with a last argument of markup? produce their last (recursively treated)
argument as default, and possibly all markup list commands with a last
argument of markup-list? similarly produce their last argument? That
leaves
Reviewers: ,
Message:
Please review.
There are some TODOs in the code where I'd appreciate some feedback.
Thanks-
Description:
Improve markup->string
'all-relevant-markup-commands' is now a toplevel-defined procedure.
So it is not longer a part of the rekursive 'markup->string'.
It
Reviewers: ,
Message:
please review
nb there are some TODO's
Description:
Improve markup->string
Search and filter lily-module for all relevant markup-(list)-commands
to prevent error-prone manual selecting.
Special-casing put-adjacent and fill-with-pattern
Please review this at ht
As usual with parser patches, i'm not the right person to review them...
i think this one is ok.
Thanks,
Janek
https://codereview.appspot.com/8102043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://code.google.com/p/lilypond/issues/detail?id=1482
Hello lists,
using \fromproperty, \smallCaps (=\caps) and markup-string leads into
some pitfalls:
1. if you want to use custom (self written) markup-commands, the default
markup-string function will drop the content of them.
2. if you
25 matches
Mail list logo
