wxTextFile: don't loose data with CRCRLF line endings.

Previously, when reading files with completely nonstandard - but
occurring in the wild thanks to broken Notepad - files with CRCRLF, all
content would be replaced with empty lines.

Fix the code to do what many editors do with such files: treat this as
data line followed by an empty one. This is not ideal, but it is better
than discarding data - and arguably, silently cleaning up the endings
wouldn't be great either (and would add extra complications for what is
an obscure and broken case).

See http://stackoverflow.com/questions/6998506/text-file-with-0d-0d-0a-line-breaks

git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/branches/WX_3_0_BRANCH@75388 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775

src/common/textfile.cpp

@@ -245,9 +245,23 @@ bool wxTextFile::OnRead(const wxMBConv& conv)
             case '\r':
                 if ( lastWasCR )
                 {
-                    // Mac empty line
-                    AddLine(wxEmptyString, wxTextFileType_Mac);
-                    lineStart = p + 1;
+                    wxString::const_iterator next = p + 1;
+                    // Peek at the next character to detect weirdly formatted
+                    // files ending in CRCRLF. Without this, we would silently
+                    // loose all the lines; this way, we insert empty lines
+                    // (as some editors do), but don't loose any data.
+                    // See here for more information:
+                    // http://stackoverflow.com/questions/6998506/text-file-with-0d-0d-0a-line-breaks
+                    if ( next != end && *next == '\n' )
+                    {
+                        AddLine(wxString(lineStart, p - 1), wxTextFileType_Mac);
+                    }
+                    else
+                    {
+                        // Mac empty line
+                        AddLine(wxEmptyString, wxTextFileType_Mac);
+                    }
+                    lineStart = next;
                 }
                 //else: we don't know what this is yet -- could be a Mac EOL or
                 //      start of DOS EOL so wait for next char