On 2012-08-20 22:13, Stefan Küng wrote:
> On 20.08.2012 21:19, Oto BREZINA wrote:
>> On 2012-08-20 21:03, Stefan Küng wrote:
>>> On 20.08.2012 20:40, Oto BREZINA wrote:
>>>
>>>>>> 7.
>>>>>> If I read code correctly On CFileTextLines::CheckLineEndings you detect
>>>>>> EOL_LFCR, but in CFileTextLines::Load this is one is decoded as EOL_LF
>>>>>> and EOL_CR or EOL_CRLF.
>>>>>> Is this intentional?
>>>>>> I guess EOL_LFCR is too rare to be really wanted, but why to detect it
>>>>>> in Check then. This makes all EOL_AUTOLINE EOL_LFCR.
>>>>> I don't understand what you mean here.
>>>>> In Load(), the line endings are checked by calling CheckLineEndings(),
>>>>> there's no separate detection.
>>>> CheckLineEndings can detect EOL_LFCR, Load not. Is this what you want?
>>> Load() calls CheckLineEndings(), which can detect EOL_LFCR.
>>> Or am I missing something here?
>> You are right - I miss this point so I was not clear enough:
>>
>> Load() on begining calls CheckLineEndings() to select right AUTO EOL -
>> is support four OELs.
>> But when analyzing file text it does not recognize EOL_LFCR.
>>
>> for (int i = 0; i<nReadChars; ++i)
>> '\r' + '\n' -> EOL_CRLF
>> '\r' -> EOL_CR
>> '\n' -> EOL_LF
>>
>> '\n' + '\r' is not recognized for EOL_LFCR here.
> in that case, that would be a bug.
And what is resolution? Do not detect it on Check or add support to Load
and EOL change - Ctrl+Enter, and draw it, or do not AUTO detect it. In
fact it is quite rare and in edge case may lead to other issues.
Let say you mix Linux (LF) and windows (CRLF) EOLs - not good but common
case - then LF + CRLF would become LFCR + LF, what may be fine until you
edit second line ...
> Stefan
>
--
Oto ot(ik) BREZINA - 오토
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=757&dsMessageId=2999903
To unsubscribe from this discussion, e-mail: [dev-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2012-08-21 15:58:04 CEST