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
Received on 2019-01-10 23:46:34 CET