bug-lilypond
[Top][All Lists]
Advanced

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

Re: Incorrect point-and-click URIs of files with non-ASCII content on Wi


From: Harmath Dénes
Subject: Re: Incorrect point-and-click URIs of files with non-ASCII content on Windows
Date: Fri, 30 Oct 2009 14:19:06 +0100

How is the tab width determined? In my case, it was always 8, so it's superfluous I think. And also IMHO there's no sense in differentiating character & byte offset. They are misleading. I'd propose keeping only the character offset, which does not take tab width into account, but correctly counts UTF-8 characters.

thSoft

On 2009.10.30., at 4:07, Patrick McCarty wrote:

On 2009-10-29, Harmath Dénes wrote:
On 2009.10.29., at 22:12, Patrick McCarty wrote:
It *should* have an effect. But if I'm thinking about this correctly,
there will still be an off-by-one error in the character/column
counts, because my commit only affects the value of the character
count when non-ASCII characters are found.

I don't understand this completely, but it doesn't matter, if the
column number in the error messages and at least one of the column
numbers in the point-and-click hyperlinks will be right.

I see the reason for confusion now.  Let me outline the various cases:

 1) All ASCII characters.  In this case, the character and column
 will always be the same, as in "3:10:10".

 2) Tab characters.  When tabs are used, the column number is
 typically greater than the character number (unless you use a tab
 that is one character wide).  An example might be "1:1:8".

 3) UTF-8 characters.  In UTF-8 locales, terminals need to know about
 the byte offset, so I am using the character count to specify this
 offset.  An example would be "3:11:10".

The third case is arguably misleading, so maybe it should be changed
to use the "3:10:10" instead.  I am okay with either format.  If we
want to use "3:10:10" instead, then an additional parameter would be
needed to calculate the byte offset.


-Patrick





reply via email to

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