The Perl regular expression search string \r(?!\n) finds a carriage return with next character not being a line-feed. I have no other suggestion at the moment for editing a file with some lines ending with only CR then using a regular expression replace to find them and replace them with nothing, a space or CR+LF. I have reported all I could see with my test file (changes.txt with 5 lines inserted at top with second and third line ending as described) by email to IDM support. So at the moment I can only agree that handling of a file with mixed line endings in file is not working as expected from UE v22.20 to v24.20 depending on configuration. I could see even with UE v22.20 and v24.20 and with having Automatically convert to DOS format selected that a file with first line ending with carriage return + line feed, second line ending with only line-feed, third line ending with only carriage return and all other more than 2000 lines in my test file ending with CR+LF results in ignoring the single carriage return at end of third line and converting all 0D 0A to 0D 0D 0A which is definitely a wrong behavior too. And of course not displaying the carriage return at all and the strange display on making a selection is definitely a wrong behavior which must be reported by email to IDM support. I agree that the behavior with interpreting a single carriage return like a normal whitespace character in a line is not what a user expects. I have not analyzed further with even older versions of UltraEdit if only CR in a file with mainly CRLF line endings is displayed ever different in the past.
The change on display of a carriage return only in a file with mixed line endings happened on UE v24.00 according to my tests on which UltraEdit became a full Unicode aware application which resulted in lots of changes in code. There is no issue on making a selection including carriage return or the text in same line after the carriage return with UE v22.20 and v23.20.
The code value is 13 decimal of this whitespace character displayed like a space as I can see on using command Character Properties on this character. But the carriage return is at least displayed like a space. The MAC terminated line is also with UE v22.20 and v23.20 merged on display with the next line in file. The DOS and UNIX terminated lines are displayed like in UE v24.20. The display is a bit different with same default settings for DOS/Unix/Mac handling with UE v22.20 and UE v23.20. There is no issue on making a selection including LF or on selecting a text right to LF in the line. The line ending with only LF is also merged on display with next line without showing LF character at all on enabling option Only recognize DOS terminated lines (CR/LF) as new lines for editing. Well, this issue with display of unprintable characters in selected text is fixed in UE v24.20.0. But on making a selection where the carriage return is included or on selecting a text in line right to carriage return, strange things happen as suddenly a space is displayed somewhere in selection. The carriage return is not displayed at all. This line is merged on display with the next line. The line ending with only LF (UNIX) and line ending displayed with ¬.īut the line ending with only CR (MAC) is not recognized as separate line. The line ending with CRLF (DOS) and line ending displayed with ¶. I can see with these settings on opening a file with all 3 types of line terminators with UE v24.20.0.44: Status bar shows original line terminator format (on disk): not checked.Save file as input format (Unix/Mac/DOS): checked.Only recognize DOS terminated lines (CR/LF) as new lines for editing: not checked.Unix/Mac file detection/conversion: Never prompt to convert files to DOS format.The default settings at Advanced - Settings or Configuration - File handling - DOS/Unix/Mac handling are:
I suppose you mean UltraEdit for Windows v24.20.0.44 with UltraEdit now.