Allow parentheses in `[alt:]` text

[rpspringuel]

As a side question: is there a way to have that numbering on top of the last note as in the source? [alt:] doesn't allow parentheses...

Originally posted by @olivierberten in https://github.com/gregorio-project/gregorio/issues/1506#issuecomment-771885609

[rpspringuel]

I think the solution here is to have backslash escapes on parentheses to allow them to be passed through as characters to the gtex file.

We might also want to do the same for square brackets, curly braces, and angled brackets.

[henryso]

At first glance, this doesn't seem too hard to do (it can be done in the lexer). We'd also need to escape backslashes of course. The only potential issue is if we somehow end up with reduce-reduce conflicts in the parser, but I don't think that's likely. This would force a major version bump as it changes the behavior of a backslash in gabc.

[rpspringuel]

We've already got a pending major version bump on the develop branch, so that's not really a big deal.

How do we get into an alt context within the notes? I don't see anything that will match the [alt: tag within a notes context in gabc-score-determination.l.

[henryso]

I think we need a different escape character than backslash because of the TeX-relationship with gabc. Gabc naturally passes backslashes through and by side-effect more than express intent, it gets into TeX. Otherwise, this might break too many things. Something typographically uncommon in lyrics, like # or $ or | perhaps?

[rpspringuel]

Well, the [alt:] tag is in the notes, so it should be typographically uncommon there too. That rules out |, which is used for the nabc cut. Personally I think the $ is probably the lesser used symbol in chant (# might be used with verse numbers).

_{Sent with GitHawk}

[henryso]

I'll use $. The complication now is that I need to re-escape characters for gabc output. I can just always escape $, -, {, }, (, [, ], <, and %. However, escaping ,, ;, :, and . allows them to lose their protrusion effect, so it'll be somewhat more difficult to detect this and escape them only when necessary they're supposed to be escaped.

[henryso]

OK, I'm getting there... How important is it to eliminate superfluous escapes in gabc output?

For example, g,g,(g,g,) will emit as g$,g,(g,g,). This is technically correct, but that $ is not really necessary for proper parsing.

[rpspringuel]

As long as the $ doesn’t make it into the TeX (where it would trigger math mode), I don’t think I would be bothered by it.

_{Sent with GitHawk}

[henryso]

I think this is ready for review.

[rpspringuel]

Working on it now.

[henryso]

Ok, the close parenthesis is causing some issue in switching from one lexer to another. Looks like the close parenthesis needs to be escaped in some cases after all. I've got to dig to figure it out.

[henryso]

OK, I think I've gotten it now. Let me know if you think of any other obscure cases.