Do we, or can we, have UTF-8 encodings in python? I'll describe what I'm doing below. The issue isn't whether I can do it on my system, which I can, but whether CVS and the rest of our build environment will preserve it if I submit a patch with a utf-8 encoded character in a python string.
I had to do another patch to abc2ly. The \version it's writing in the file is wrong, and that's easier to fix than to report. So I decided to look at the problem I reported last week about multiple title lines. I decided that the previous behavior of a second T: line was quite similar to that of an S: (subtitle) line, so the right thing would be to leave the second T: line on the same line as the first, but with some punctuation (other than the current \\\\) between them. The punctuation I've actually used for this sort of thing in my own transcriptions is a TeX punctuation dash (---), and if I use the utf-8 encoding and the TeX input method in my abc2ly.py buffer, I don't have any trouble entering such a character into the file. When you run the file, a python warning points you to the standard for telling python what kind of encoding is being used for non-ascii characters, so I added that line to the file, and it now runs without errors, and produces a fine dash in the title line. But before I send the patch, is that UTF-8 character in my python file going to make it through the build system? And is it going to survive future coders who may be using editors which don't display the character correctly? (The font I'm using actually doesn't either, but of course I know what I entered.) And even if it survives it this time, do the developers want to have a policy about how or whether to do this? If the policy ends up being that we should do it, the python files with utf-8 characters in them will need to have: # -*- coding: utf-8 -*- as their second line. -- Laura (mailto:[EMAIL PROTECTED] , http://www.laymusic.org/ ) (617) 661-8097 fax: (501) 641-5011 233 Broadway, Cambridge, MA 02139 _______________________________________________ lilypond-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/lilypond-devel
