[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
Re: Incorrect point-and-click URIs of files with non-ASCII content on Windows
Thu, 29 Oct 2009 20:07:01 -0700
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.