8

I am looking at some Java Code in Eclipse on Windows. The line termination characters (DOS-style) do not display properly (empty lines everywhere..).

The Problem is that the Code is from a Windows ClearCase vob for which I do not have check-in permissions, so it is read-only (changing the line-termination characters with auto-format is not possible). Creating a full copy and changing the line termintators is out of the question as the code might change while I am looking at it..

I found Preferences->Workspace->"New text file line delimiter", but it seems that this does not display the line termination characters in existing files properly.

How do I make eclipse display the text file as it was meant to display?

Edit: Notepad displays the file correctly. Ultra-Edit also detects it as unix-style and suggests converting it to DOS (but displays properly when declining it). gvim detects the file as unix and displays ^M and the end of the line.

I have checked the file in binary and it does not contain any \n characters that do not follow a \r character. Could there be any other way that Eclipse distinguishes unix from dos-style line endings?

I found this sequence of characters: 0d0d 0a0d 0d0a (\r\r\n\r\r\n). I suppose this is why it does not work..

0x89
  • 2,940
  • 2
  • 31
  • 30
  • I did some preliminary research and testing. I found that this has nothing to do with Eclipse per-se but has to do with the actual files themselves. They are getting wrongly encoded when checked into version control systems like SVN and CVS, so when they get checked out, they get what is shown as double-lines in Eclipse whereas single-lines in other editors. You can temporarily solve the problem by replacing (Replace All) ` ^p` (that is not a space) with `^p` using UltraEdit but the permanent solution is correct SVN/CVS configuration. – ADTC Sep 11 '12 at 02:50

4 Answers4

4

What OS are you running on? Eclipse auto detect line terminators. I never seen it fail and display extra newlines. is it possible that your file actually does not double newlines? maybe try to view it with another editor (notepad++, editplus)

Omry Yadan
  • 31,280
  • 18
  • 64
  • 87
  • 1
    *Eclipse auto detect line terminators. I never seen it fail* Me neither (+1) – Sean Patrick Floyd Nov 05 '10 at 09:46
  • Well, it is probably a quite sick setup that I have to work in - Windows and unix Clearcase are mixed, files are also transmitted in various other ways and there is outsourcing (to a country far, far away) involved.. – 0x89 Nov 05 '10 at 10:19
  • you need everyone on the project to agree on some newlines type and stick with it. you can use Eclipse to convert the line terminators (file->convert newlines or something). – Omry Yadan Nov 08 '10 at 10:14
1

Go to Preferences->General->Workspace You will see Text file encoding where you can change it to the encoding you prefer and there is the New text file line delimiter where you have to option of using unix, windows or mac os

s-hunter
  • 24,172
  • 16
  • 88
  • 130
1

I had the the same issue with end-of-lines and I notice the problem of quick visibility in Eclipse (compared with e.g. Notepad++) but I notice it can be quickly found by using a built-in feature:

In the toolbar there is a button "Show Whitespace Characters" (symbol Pi: ¶) and when you press it, you will have one of these character at the end of line:

  • ¤¶ for a file with Windows EOL (CRLF)
  • for a file with Unix EOL (LF)

That way you can just see what EOL encoding you have and convert it by using the File menu.

If you use for example git, you can also set up an option to automatically convert all the commits with a specific EOL. But sometimes for an unknown reason, the files gets with Windows EOL even I am using Eclipse under a Linux VM. The Eclipse built-in feature permits to see in one sight what is the encoding.

рüффп
  • 5,172
  • 34
  • 67
  • 113
0

We are in a mixed-environment with ClearCase (Unix VOB server) and Windows ClearCase clients, and with Eclipse.

I haven't observed such an issue, but I know that certain type can be managed by ClearCase in a specific way: see Working with Rational ClearCase Unicode Type Manager.
By describing (cleartool describe) the type of the files causing the problem, you might see a special file type which could be a first explanation.

Another classical reason could include a ClearCase trigger which would somehow corrupt the content of said file.

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • I think the problem is rather the missing discipline (and technical knowledge) of the developers. Somebody somehow figured out how to add a few extra \r to the file, see above.. – 0x89 Nov 05 '10 at 12:25