#3854 Windows line ending (CR/LF) in version 5.1
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,
I have been using jedit 5.1 on Windows and I have never seen this happen. By moving lines, what jedit command are you exactly talking about that can reproduce this problem ? Like anybody else using an editor I am often moving lines about and jedit has never produced the sort of incorrect line ending you claim. So please try to be specific about what is causing the problem which you are seeing.
Well - I already tried to be as explicit as possible: I used the Move Line Up macro from the Macros/Editing menu. But the bug is seemingly not caused by the macro itself. In an attempt to narrow down the problem I cut away most parts of the macro. Result: Even the single command "buffer.insert(end_offset,lineSeparator)" produces a wrong "CR CR/LF" line ending. Obviously the inserted text gets parsed after the insert command - and gets a wrong line ending correction.
Update: I just checked the lastest daily build (2014-04-21) of jEdit 5.2pre1
-> the same problem as in 5.1.
Maybe relative to https://sourceforge.net/p/jedit/bugs/3900/
I confirm the problem using Macro, Editing, Move Line Up is also in windows 7, jEdit 5.1.0, Java 1.8.0_20.
If line 2 is moved up (or down), after the move, the new 2nd line ends in CRCRLF instead of CRLF.
Is it still a bug ?
Hard to say: After this (and other bugs) I switched to VIM and never looked back...