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.

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