[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: David Kastrup
Subject: Re: Lilypond's error column printer confuses bytes and characters
Date: Thu, 22 Oct 2009 12:42:20 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (gnu/linux)

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.
      wchar_t multibyte[2];
      size_t thislen = mbrtowc (multibyte, line_chars, left, &state);
      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

David Kastrup

reply via email to

[Prev in Thread] Current Thread [Next in Thread]