Re: [abcusers] Re: continuations
On 22 Jul 2003 18:07:47 -0400, Laura Conrad [EMAIL PROTECTED] wrote: When I started using the -c option on abc2ps, I was quite surprised when some of my 8th notes were beamed, because only a newline separated them, whereas most of them were not, because I had deliberately put spaces between them. I thought that most people would assume that any whitespace, including newline, would cause the 8th's to not be beamed. abcm2ps adds a space at the end of every line (but not in continuation lines), as you asked me some time ago, but I am not happy with that: I would have use this fact (no space) to implement un-terminated beams at end (and start) of lines. BTW, the problem is more general: how may I have also beams crossing bars... -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** | http://moinejf.free.fr/ Pépé Jef| mailto:[EMAIL PROTECTED] To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Re: continuations
From: Phil Taylor [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, July 23, 2003 2:59 AM Subject: Re: [abcusers] Re: continuations John Chambers wrote: Another fringe case is what happens when a line ends with '\', a space, and a newline. It's common for many implementations to not recognize this as a continuation. This one is really baffling to a user, who usually can't see the space. The right way to handle this is to strip off the trailing spaces (and tabs), and then check for the final '\'. The input routine is now not quite as trivial (though it's still pretty trivial). BarFly does that (at least for spaces - I'm not sure about other whitespaces). Another thing that's a problem is % comments following the backslash. That's more complicated to deal with, and I'd like to see it illegal. I'd second that! Arent To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Re: continuations
Arent Storm writes: | From: John Chambers [EMAIL PROTECTED] | | Another fringe case is what happens when a line ends with '\', a | space, and a newline. It's common for many implementations to not | recognize this as a continuation. This one is really baffling to a | user, who usually can't see the space. The right way to handle this | is to strip off the trailing spaces (and tabs), and then check for | the final '\'. The input routine is now not quite as trivial (though | it's still pretty trivial). | is not so straightforward Actually, it's fairly easy. What I did with my (jcabc2ps) clone was to put code in the getline() routine that does this: First, replace all trailing whitespace chars with NULs. Trailing whitespace chars are never significant in abc. Wiping them out during input slightly simplifies later parsing. Next, if there's a '\' at the end of the line, read another line, overwriting the '\' with the first input char. Repeat until there isn't a '\' at the end (or realloc() fails). I did have to change the input buffer from a fixed-size buffer to one that could be realloc'd, plus a variable saying how big it is. This was fairly easy. I did check all the references to see if there was anything that would break. I didn't find anything. This wasn't surprising, since the program obviously shouldn't keep any info about the input from one line to the next. Also, there's one bit of trickiness: abc2ps has an option to ignore final '\' and use the line breaks in the abc. If this option is set, the first step should just treat '\' as whitespace and NUL it out. The second step then never sees a '\'. To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
[abcusers] Re: continuations
I. Oppenheim writes:
|
| I think this broken continuation mechanism of the Old
| Standard is one of the most serious design mistakes in
| the whole ABC notation system.
|
| Should we continue to support it, or should we change
| the standard to be more sane---giving up backward
| compatibility? Maybe we should have a vote on this
| issue?
Actually, there is little backward compatibility to give
up, because current abc tools have a great deal of
incompatibility in how they implement continuations.
As has been discussed before, the basic problem is with the
idea that a continuation of a line means to join it with
the next line of the same type. This turns out to be a
very fuzzy phrase, and different programmers interpret it
in very different ways. As a result, abc from other people
sometimes won't work until you change the continuations to
be whatever your abc tool expects.
This has been thrashed out for many programming languages
over the past several decades. It turns out there's only
one rule that will actually be implemented the same by all
programmers, and it's also the only rule that users will
all understand the same way. This is that the continuation
('\' in abc as in many programming languages) just means to
join the current line to the next line.
If we attempt to have the continuation mechanism skip
lines, we make life very difficult for all of us, because
there is no real hope that all programmers will implement
this skipping the same way.
We should classify the old scheme(s) as a minor mistake,
and correct it in the official standard. Then it will
finally be clear how programs should implement it, and
programs that skip lines to find the continuation will
simply be buggy. But it's an easy bug to fix.
(And we'll still have the even more minor problem caused by
the fact that some programmers will replace the '\' with a
space, while others will delete it plus the newline,
causing the two lines to be joined without a separator.
This is a problem that still plagues several programming
languages. It's made worse by the fact that there's no
logical solution; both ways work equally well. Quandaries
like this are almost impossible for a group of humans to
ever solve. ;-)
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Re: continuations
John Chambers wrote:
This has been thrashed out for many programming languages
over the past several decades. It turns out there's only
one rule that will actually be implemented the same by all
programmers, and it's also the only rule that users will
all understand the same way. This is that the continuation
('\' in abc as in many programming languages) just means to
join the current line to the next line.
I agree.
If we attempt to have the continuation mechanism skip
lines, we make life very difficult for all of us, because
there is no real hope that all programmers will implement
this skipping the same way.
We should classify the old scheme(s) as a minor mistake,
and correct it in the official standard. Then it will
finally be clear how programs should implement it, and
programs that skip lines to find the continuation will
simply be buggy. But it's an easy bug to fix.
(And we'll still have the even more minor problem caused by
the fact that some programmers will replace the '\' with a
space, while others will delete it plus the newline,
causing the two lines to be joined without a separator.
This is a problem that still plagues several programming
languages. It's made worse by the fact that there's no
logical solution; both ways work equally well. Quandaries
like this are almost impossible for a group of humans to
ever solve. ;-)
Er, why would you want to put a space in place of the backslash?
Joining the two lines without a separator seems the logical
thing to do (or at least I can't immediately think of a situation
where adding a space would make sense).
Phil Taylor
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Re: continuations
Phil == Phil Taylor [EMAIL PROTECTED] writes: Phil Er, why would you want to put a space in place of the backslash? Phil Joining the two lines without a separator seems the logical Phil thing to do (or at least I can't immediately think of a situation Phil where adding a space would make sense). When I started using the -c option on abc2ps, I was quite surprised when some of my 8th notes were beamed, because only a newline separated them, whereas most of them were not, because I had deliberately put spaces between them. I thought that most people would assume that any whitespace, including newline, would cause the 8th's to not be beamed. -- Laura (mailto:[EMAIL PROTECTED] , http://www.laymusic.org/ ) (617) 661-8097 fax: (801) 365-6574 233 Broadway, Cambridge, MA 02139 To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Re: continuations
On Wed, 22 Jul 2003, Laura Conrad wrote: I thought that most people would assume that any whitespace, including newline, would cause the 8th's to not be beamed. When you precede a newline by a backspace, the newline gets escaped and no longer functions as whitespace. Groeten, Irwin Oppenheim [EMAIL PROTECTED] ~~~* Chazzanut Online: http://www.joods.nl/~chazzanut/ To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Re: continuations
Phil Taylor writes: | John Chambers wrote: | (And we'll still have the even more minor problem caused by | the fact that some programmers will replace the '\' with a | space, while others will delete it plus the newline, | causing the two lines to be joined without a separator. | This is a problem that still plagues several programming | languages. It's made worse by the fact that there's no | logical solution; both ways work equally well. Quandaries | like this are almost impossible for a group of humans to | ever solve. ;-) | | Er, why would you want to put a space in place of the backslash? | Joining the two lines without a separator seems the logical | thing to do (or at least I can't immediately think of a situation | where adding a space would make sense). Well, I tend to agree. But I think the contrary argument is that a lot of people are surprised when the two lines are joined without a space. They then have to go back and fix it (e.g. by putting a space before the '\'). I think the idea is that this Oops! reaction wastes more time than the alternative. But note that I called this an even more minor problem. We're really on the fringe here, and it's probably not worth wasting much time on. I'd also vote for making a final '\' delete both itself and the newline, and join the next line without adding anything. You can always put a space before the '\'. Another fringe case is what happens when a line ends with '\', a space, and a newline. It's common for many implementations to not recognize this as a continuation. This one is really baffling to a user, who usually can't see the space. The right way to handle this is to strip off the trailing spaces (and tabs), and then check for the final '\'. The input routine is now not quite as trivial (though it's still pretty trivial). To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Re: continuations
John Chambers wrote: Another fringe case is what happens when a line ends with '\', a space, and a newline. It's common for many implementations to not recognize this as a continuation. This one is really baffling to a user, who usually can't see the space. The right way to handle this is to strip off the trailing spaces (and tabs), and then check for the final '\'. The input routine is now not quite as trivial (though it's still pretty trivial). BarFly does that (at least for spaces - I'm not sure about other whitespaces). Another thing that's a problem is % comments following the backslash. That's more complicated to deal with, and I'd like to see it illegal. Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
