Patrick McCarty <pnor...@gmail.com> writes: > On 2009-10-18, David Kastrup wrote: >> >> GNU LilyPond 2.13.4 >> Processing `bad.ly' >> Parsing... >> bad.ly:4:16: error: syntax error, unexpected MUSIC_IDENTIFIER >> MÃÃÃ A\342\231 >> \257 Bâ \break >> error: failed files: "bad.ly" >> >> Apparently, the error column is being tracked by counting characters, >> but is displayed by counting bytes. The indicator appears too early >> because of that (which caused me to look for the wrong bug in an input >> file of mine). > > This patch seems to correct the issue, but I don't know if it's the > correct fix (or if there are any side effects I'm unaware of).
The code before states: while (left > 0) { /* FIXME, this is apparently locale dependent. */ #if HAVE_MBRTOWC wchar_t multibyte[2]; size_t thislen = mbrtowc (multibyte, line_chars, left, &state); #else size_t thislen = 1; #endif /* !HAVE_MBRTOWC */ The question is what we do about locales. I think that in this case behavior is arguably correct since we are talking about column numbers on the terminal/locale, and even when Lilypond is using utf-8, those will correspond with the interpretation of the locale. Or something. Anyway, it seems like this change would cause the surrounding function to behave more consistently. As to consistency: when I switch into POSIX locale, the error message will occur before the first Umlaut which is then no longer considered text apparently. So we already have some built-in locale dependencies elsewhere. -- David Kastrup _______________________________________________ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond