[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 14:12:34 -0700
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
> 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.