Re: convert-ly for note/rest-markup

[Aaron Hill]

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
> > > nightmare.
> >
> > 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