[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: convert-ly for note/rest-markup

From: Aaron Hill
Subject: Re: convert-ly for note/rest-markup
Date: Thu, 11 Feb 2021 16:14:53 -0800
User-agent: Roundcube Webmail/1.4.9

On 2021-02-11 2:54 pm, Michael Käppler wrote:
Am 11.02.2021 um 23:39 schrieb Aaron Hill:
On 2021-02-11 2:04 pm, David Kastrup wrote:
Short of special-patterning the known exceptions...  a bit of a

Does the pattern matching need to be so particular about context?
Consider a primitive approach:

  re.sub(r'\\note\s*#"([^"]+)"', r"\\note { \g<1> }", ...)

This matches the `\note #"..."` pattern, converting to `\note { ... }`.
I agree that this should work for most cases, but consider that it can't
be taken for
granted that '\note' refers to the markup function:

note = { c4 }

\markup \note #"4." #UP
\note #"4." #UP

I don't want to say it makes any sense, but it is valid input...

Maybe "valid" is not the best litmus test. The second line is music followed by a string and a number at the top level. If I did not actually test this with 2.22.0 and see it work, I would have told you that would fail to compile. Seems the parser consumes the Scheme-escaped string and number with no complaints, but there appears to be no purpose to such a construct.

I apologize if I am being flippant; but permit me to point out that in your example, if we apply the primitive conversion rule, the result is still valid input:

note = { c4 }

\markup \note { 4. } #UP
\note { 4. } #UP

Only difference is an additional staff and note appears, so the useless string before actually does something.

At the end of the day, I would argue convert-ly should not attempt to cater to the exotic. `\note #"..."` is distinctive enough a pattern that broadly it will not be misinterpreted. Certainly, the pattern could be expanded to include the second argument, which makes false matches less likely. Additionally, you could go as far as validating the string contains a suitable duration. But there is always a risk of overdesigning the regular expression, wasting engineering and execution resources for no realized gain.

-- Aaron Hill

reply via email to

[Prev in Thread] Current Thread [Next in Thread]