#642 Wrong EOL character

[Anonymous]

I am using WinMerge v2.1.7.9 with Win XP.

Editing a file in Unix format (EOL: LF) the 'Enter' key
insert an EOL in DOS format (CRLF).

[Kimmo Varis]

Logged In: YES
user_id=631874

You are in 'mixed EOL' mode. I'm not sure about method for
determining new EOL char in that mode.

Does WinMerge insert DOS EOL if you uncheck 'Preserve
Original EOL chars' checkbox from Options/Editor?

[Nobody/Anonymous]

Logged In: NO

I think we are talking about the internal representation vs.
the input/output format here. If program was able to read the
text file then it "knows" lines and therefore a new line
addition, regardless of what user did on a particular platform
and ui.

So what the guy refered to as the ['Enter' key] at the end of
the line is the [add empty line] request - nor particular EOL
delimiters involved until the file is saved to disk.

Depanding on the way of user action detection (checking CR,
LF, CR/LF chars or having event handler for 'Enter' key) it may
be easier or less easy to handle it. If all chars are accepted
blindly then 'Enter' trigger has to go back and kill
traliling "currentEOL" in the line he's closing. The "currentEOL"
being CR/LF for non-Unix PC and non-Unix Mac :-))

Following this to it's ultimate consequence it also means that
the 'Preserve Original EOL chars' really means "keep the
regular EOL found in input file" and not "keep each lines
possible trash at the end. Pobably the area Winmerge didn't
enter yet - some "overfriendly" software ends up inserting
trashy EOL's (like CR,CR,LF) which have to be nuked just to
have regular lines.

Utility like WinMerge actually has a wider poetic license for
EOL cleanup (which text editors also doing hex don't) which
gives a rather fast 0-lookahead rule:

{LF ==> EOL, CR ==> void} unless box == Mac :-)

For a Mac, one needs to scan a few lines to determine the
dominant EOL (possibly yelling an alert box for weird stuff)
and it if happens to be a CR, then 1-lookahead 1-lookbehing
rule is needed:

{CR ==> EOL, LF ==> EOL if next!=CR && prev!=CR otherwise
void }

[Kimmo Varis]

Logged In: YES
user_id=631874

Oh, this is obvious bug. In void CCrystalEditView::OnChar()
we always add DOS-EOL.

Fix is also simple, instead of hard-coded DOS-EOL we must
ask EOL from buffer (CCrystalTextBuffer::GetDefaultEol()).

Unfortunately seems we have a wrong EOL type in buffer..

[Kimmo Varis]

Logged In: YES
user_id=631874

Patch for ccrystaleditview.cpp, CCrystalEditView::OnChar ()

--- ccrystaleditview.cpp 24 May 2004 04:36:51 -0000 1.16
+++ ccrystaleditview.cpp 2 Sep 2004 13:31:10 -0000
@@ -483,7 +483,7 @@
else
ptCursorPos = GetCursorPos ();
ASSERT_VALIDTEXTPOS (ptCursorPos);
- const static TCHAR pszText[3] = _T ("\r\n");
+ LPCTSTR pszText = m_pTextBuffer->GetDefaultEol();

int x, y;
m_pTextBuffer->InsertText (this, ptCursorPos.y,
ptCursorPos.x, pszText, y, x, CE_ACTION_TYPING); // [JRT]

I'll apply this once I have applied another patch (#1021153
Fix ansi files EOL detection in unicode builds).

[Kimmo Varis]

Logged In: YES
user_id=631874

Now that I applied that another patch to fix EOL detection,
I can fix this too.

(This) Patch applied to CVS. Closing as fixed.