David has pointed out to me that what was tripping me up with this file
was a CR character (0x0D) which is white space and is treated as such,
but editors should not treat it as starting a line, which the
GtkSourceView widget was doing.
So looked at in (for example) gedit, the line count was wrong,
Am 24.10.2014 um 13:59 schrieb Richard Shann:
On Fri, 2014-10-24 at 11:15 +0200, Helge Kruse wrote:
Thank you for your response.
I think you should not added control characters like newline to the
markup text.
yes, perhaps that is the case - I assumed any white space was
acceptable, but it seem
On Fri, 2014-10-24 at 11:15 +0200, Helge Kruse wrote:
Thank you for your response.
> I think you should not added control characters like newline to the
> markup text.
yes, perhaps that is the case - I assumed any white space was
acceptable, but it seems in some circumstances to trigger this undesi
I think you should not added control characters like newline to the markup
text.When you want to have more than one line, please use the \column
markup.
http://lilypond.org/doc/v2.18/Documentation/notation/formatting-text#index-font-families
\markup{
\column {
\bold{hi}
""
}
}
Regar
In the following lilypond the location reported for the line of notes
after the markup is off by one. The d's are reported at line 5 when they
are on 6 etc. The first c'4 is correctly reported as being on line 3.
8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><
\version "2.18.
