Description: Starting with jEdit 5.1 there is a grave problem with the Windows line ending option (CR/LF=/r/n). I came across this problem using the Move Lines Up/Down macros from the Macro/Editing menu. After moving a number of lines several times up the file becomes more and more disfigured, reaching either the upper or lower end renders the text completely useless. The problem is not just aesthetics but the saved version is crippled as well.
Trying to track down the problem revealed the following clues:
1) The problem is not present in version 5.0.
2) It is only present with Windows, not with Unix or Mac line ending.
3) Looking at the corrupted file in hex mode the strange behavior can be attributed to a bug with the line endings: When a line is moved it is not inserted with “CR/LF” but with “CR CR/LF” line ending.
4) Although the macros for moving text have changed from 5.0 to 5.1 they are not likely the real cause of this behavior: In line 81 the line separator of the system is determined - absolutely correctly as “CR/LF”. Changing this line to “String lineSeparator = "#"+buffer.getStringProperty( "lineSeparator" )+"#";” should result in a line break in form of “#CR/LF#”. Actually it is “#CR CR/LF” after each freshly inserted block of text.
5) The complete garbage at the end/beginning of the file seems to be a result of the superfluous CRs in the file.
6) Switching to Unix/Mac line end encoding results in a correct “#LF#”/”#CR#”.
Conclusion: Some function executed after the macro falsely corrects the line ending in files with Windows CR/LF setting.
Platform: Win XP 32-SP3, Java 1.7.0_45,