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

[Patrick McCarty]

2009/10/29 Valentin Villenave <address@hidden>:
> 2009/10/29 Harmath Dénes <address@hidden>:
>> No, the two are very different.
>> In http://code.google.com/p/lilypond/issues/detail?id=887, the _filename_
>> part of the URIs is wrong because of non-ASCII _filenames_.
>> In this bug (http://article.gmane.org/gmane.comp.gnu.lilypond.bugs/16097),
>> the _column position_ part of the URIs is wrong because of non-ASCII
>> _content_.
>
> Interesting. Patrick, doesn't it look a lot like David's report on
> http://lists.gnu.org/archive/html/bug-lilypond/2009-10/msg00049.html ?

It is very similar, and the problem probably stems from the same
function, namely Source_file::get_counts().

>> Anyway, as mentioned, the latter is more general, and is related to not the
>> PDF generation, but the position calculation, since it occurs in
>> command-line compiler errors too.
>
> Yes, which is why I'd like to know if Patrick's recent work on David's
> report could have affected this one as well.

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.

-Patrick