Jack Campin writes: | >> |: CEC DED |1-3 EGE FAF :|2,4 EFG FED :|["last time" EFG ABc :| | > Wouldn't it be best to avoid unmatched bracket symbols? | | "[" isn't used as a bracket here; it's used to mark a repeat number, and | has to be so used if the variant bit doesn't start at the beginning of | the bar. I use it all the time, even when the variant starts at the | barline, as I find it simpler to have only one syntax for this, it's | more clearly visible than the more concise form, and it makes editing | simpler if I want to move the start of the repeat.
Me too. But this does remind me of Yet Another Extension that I've been thinking of proposing. The problem is that there's no way to mark the end of an ending. I have a couple example where the second ending is longer than the first. What abc2ps does is assume that the endings are the same length. This looks a bit funny, though I suppose it's musically harmless. A possible solution that's backwards compatible and wouldn't break any current abc is to say that ']' may be used to terminate endings. If there isn't a matching ']', then the first :| or any sort of double bar terminates the ending. This would allow the ']' to be omitted for all the normal cases with endings of equal length. Then you could write: |: ... | ... |[1 ... ]:|[2 ... | ... ]| In this example, the first ']' could be omitted, since it is followed by :|, but the second ']' would be needed if you want to make it clear that the second ending included two bars. You could also omit both of the '['s in the above, of course, though Jack and I probably wouldn't. This would sorta overcome the aesthetic objection to the use of an unclosed bracket in abc's syntax. You could just say "Well, they actually are balanced. The syntax just permits omitting the close bracket before :| and double bars. So the close bracket is there by implication. Some programming languages have similar rules that permit closing brackets of various types to be omitted if a "higher level" token is encountered. They often allow list separators such as comma or semicolon to be omitted before tokens like right paren or right brace. The parser just fills in the missing terminator tokens. This suggestion is similar. And if implemented, it would make it possible for us overly picky types to get printed ending brackets just right. To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
