Re: Lilypond's error column printer confuses bytes and characters

[David Kastrup]

Patrick McCarty <address@hidden> 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.  It works in my case.

By the way: 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.

My vote is on getting it merged, but it probably would do no harm if
somebody checked this on Windows where the old version purportedly
worked.

-- 
David Kastrup