Bugzilla – Full Text Bug Listing
| Summary: | [misc] Files with non-platform line termination must be flagged | ||
|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Peter Hack <pahack> |
| Component: | Text | Assignee: | Platform-Text-Inbox <platform-text-inbox> |
| Status: | VERIFIED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | andreknabben, dj.houghton, nikolaymetchev, otaviofp, stori, thomasf |
| Version: | 2.0 | ||
| Target Milestone: | 3.1 RC1 | ||
| Hardware: | PC | ||
| OS: | Windows 2000 | ||
| Whiteboard: | |||
| Bug Depends on: | 3970 | ||
| Bug Blocks: | |||
Moving to Platform/UI for comment. Currently, there are several instances where Serializer is used. If you do not explicitly set OutputFormat.lineSeparator, it defaults to WEB which is LF. If we are writing a file into the workspace, we need to use the platform encoding. More information: org.eclipse.team.core.Team.getType(IFile file) answers if a file is TEXT, BINARY, UNKNOWN. Currently CVS assumes anything that is not explicitly text is binary. In the case of formatted templates information, it was always inserting '\n'. This is fixed now (>= 20020923). Generally, if a tool does not respect a document's delimiter setting, it is a bug. It would be a good idea to inform about and let the user set the delimiter per file. Marking as duplicate of a related bug. *** This bug has been marked as a duplicate of 3970 *** reopening, as it isn't really a dup, but rather dependent. I'm marking this one as fixed. You can use the content type to determine whether a file is a text file (keep in mind though that not all clients yet support this) and there's now a story for line delimiters (see bug 3970). verified in 3.1 RC3 |
Eclipse interactive editors (like the Java source code editor) appear to write files using the platform's line termination character(s). This is '\n' on Unix and '\r\n' on Windows. Some other non-interactive "editors" (called "process" editors in the validateEdit document) do not consistently follow this rule. For instance, the '.classpath' process editor writes '\n' even on Windows. This inconsistency can cause ugly problems with CM systems that expect all text files to use the same line termination style. These problems can be very confusing to the users (which is why I marked the Severity as "major"). They can be avoided if the CM systems knows to treat the file as something other than a text file. Thus, Eclipse needs a mechanism whereby Team providers can ask if the file/resource should be treated as something other than a text file (even though it only contains text). Any creator of a file that creates a file that will not conform to the line termination style of the platform when written must mark the resource utilizing this mechanism. -------------------------------------------------------------------------------- Historical note: When this issue was first discussed, the following solution was proposed but rejected: 1) When a file already exists, the editor must write changes out using the line termination style of the pre-existing file (i.e. that it read in when it started the edit session). 2) If the editor is writing a new file or a file that was empty, there should be a new Eclipse-wide preference that will determine the line termination style used. The preference values would be: - Platform default - Windows style ("\r\n") - Unix style ("\n") 3) If a file already exists but has a mixture of line termination styles, the editor should either ask the user for the style to use or use the style indicated by the new Eclipse-wide preference. --------------------------------------------------------------------------------