Re: Lilypond's error column printer confuses bytes and characters
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). I get this output: GNU LilyPond 2.13.6 Processing `bad.ly' Parsing... bad.ly:4:16: error: syntax error, unexpected MUSIC_IDENTIFIER Määä A♯ B♭ \break error: failed files: bad.ly If the patch looks okay, I'll add a commit summary for completeness. Thanks, Patrick From 3a0a66f7d6bc2f4791da6c3f6efeb499eed49465 Mon Sep 17 00:00:00 2001 From: Patrick McCarty pnor...@gmail.com Date: Thu, 22 Oct 2009 03:01:09 -0700 Subject: [PATCH] Fix error message output alignment for wide chars --- lily/source-file.cc |7 ++- 1 files changed, 6 insertions(+), 1 deletions(-) diff --git a/lily/source-file.cc b/lily/source-file.cc index fc5b034..96264fb 100644 --- a/lily/source-file.cc +++ b/lily/source-file.cc @@ -308,7 +308,12 @@ Source_file::get_counts (char const *pos_str0, else (*column)++; - (*line_char)++; + /* + For accurate error output, consider multibyte + characters as a series of characters. + */ + (*line_char) += thislen; + /* Advance past this character. */ line_chars += thislen; left -= thislen; -- 1.6.5.1 ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Lilypond's error column printer confuses bytes and characters
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. 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
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Issue 706 in lilypond: ledger lines should take simultaneous notes' accidentals into account
Comment #1 on issue 706 by paconet.org: ledger lines should take
simultaneous notes' accidentals into account
http://code.google.com/p/lilypond/issues/detail?id=706
% another example shows the problem on simple chords, caused possibly not
anymore by
ledger lines being printed multiple times.
\version 2.13.6
\new Staff {
ces' des 1
}
Attachments:
ledger-chord.png 2.9 KB
--
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
page-count doesn't set whole-score page count when \pageBreaks are present
According to LNR 4.1.2, the page-count setting sets The number of pages to be used for a score. The presence of a \pageBreak command in the score, however, causes the score to be split into multiple chunks, each having page-count number of pages. Effectively, the final page count of the score is page-count*(number of \pageBreak commands present + 1) rather than just page-count. A short example is at the following URL: http://temp.mvpsoft.com/ly/tests/2009-10/page-count.ly http://temp.mvpsoft.com/ly/tests/2009-10/page-count.pdf Thanks, Chris -- Chris Snyder Adoro Music Publishing 1-616-828-4436 x800 http://www.adoromusicpub.com ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Lilypond's error column printer confuses bytes and characters
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
Re: automatic accidental style voice: too many written accidentals
2009/10/20 Frédéric Bron frederic.b...@m4x.org: The patch below makes it work but breaks default style. I would like to replace (ly:context-parent context) by something that always returns the current Staff context You can't do this, since it would break 'piano style. Regards, Neil ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
