On 10.01.2019 19:13, Stefan Kueng wrote: > > > On 10.01.2019 06:58, Branko Čibej wrote: >> On 10.01.2019 04:58, Branko Čibej wrote: >>> On 07.01.2019 20:57, Stefan Kueng wrote: >>>> @@ -758,6 +759,33 @@ >>>> * will be true if the reason there is no blame information is >>>> that the line >>>> * was modified locally. In all other cases @a local_change will >>>> be false. >>>> * >>>> + * @note the line is split on LF characters. Clients must be aware >>>> of this >>>> + * when dealing with different encodings of the file/line. >>>> + * Blaming non ASCII/UTF-8 files requires the @a force flag to be >>>> set when >>>> + * calling the svn_client_blame6 function. >>> >>> I just noticed that svn_client_blame6 does not, of course, have a >>> parameter called 'force'. But it does have a parameter called >>> 'ignore_mime_type'. >> >> >> Also the assertion that "lines are split on LF" turns out to be wrong >> and misleading. Line endings are translated first, through >> svn_subst_stream_translated(), and this happens regardless of the MIME >> type. These parts of the new docstrings should be fixed before the next >> release. > > How about this: > * @note the line is split on newline bytes. Clients must be aware of > this > * when dealing with different encodings of the file/line. > * Blaming non ASCII/UTF-8 files requires the @a ignore_mime_type flag > to be > * set to true when calling the svn_client_blame6 function. > > > mentioning that the split is done on newline *bytes* should be clear > enough? > Of course, better ideas are always welcome.
I'd just write something about the contents being preprocessed by '@ref svn_subst_stream_translated' to convert newlines, as that has its own, quite extensive docstring. There's no need to second-guess that or duplicate information. Incidentally, this is probably why you don't see any CR bytes. An UTF-16 sequence of 'CR 00 LF 00' will be translated to 'LF 00 LF 00' and you'll get two callbacks out of that instead of one ... I think. -- Brane
