Community
Participate
Working Groups
I have set "Web and XML" -> "CSS Files" -> "Line delimiter to "UNIX". When I edit CSS files, the modified lines get DOS line endings. As a test I created a new CSS file, typed the following: body { font-size: 12pt; } Here's the content as seen by hexdump: $ hexdump -C test.css 00000000 62 6f 64 79 20 7b 0d 0a 20 20 66 6f 6e 74 2d 73 |body {.. font-s| 00000010 69 7a 65 3a 20 31 32 70 74 3b 0d 0a 7d 0d 0a |ize: 12pt;..}..| 0000001f
Note the problem only seems to apply to lines that have been inserted (directly or by pasting); modifying a single line does not introduce a DOS line ending.
maybe the line delimiter preference should just be removed from all XXX files preference pages and just use the preference specified in General->Editors->New text file line delimiter Is there any reason why line delimiters would be different for different content types?
I would rather have a single option controlling all text files; but then I use Unix endings exclusively even on Windows: in my opinion there's no reason to ever use DOS endings anymore, since about every application out there is able to handle both forms. The only exception I can think of is Notepad. I have reported the same bug against the HTML editor in bug 107651. Curiously enough the JavaScript editor seems unaffected by the problem.
I would like to still have the *option* of having seperate settings per content type. The use case I've heard (I'll admit a while ago) is that some some wanted it for some types (e.g. HTML) but not all (e.g. Java) since the former were "moved" to other platforms and used with other tools, but the latter wasn't. Its a good idea to have a setting (and the default?) of "use global setting". I'm not sure if we've lost the ability, but used to have another dimension of choice about "leave existing ones alone" vs. "actively convert all cases".
The way the base currently handles delimiters is users can specify the line delimiter for new files in general via the preference: General->Editors->New text file line delimiter Users can also specify the line delimiter for new files for each project via project properties (right click project in navigator, select Properties, in the Info section, "New text file line delimiter") If we want to keep the option of line delimiters per content type, that seems doable. We could just have a radio button in the preferences to either use a specific line delimiter or use whatever the base's preference is. An extra problem seems to be that our line delimiter preferences say we will convert all line delimiters to the line delimiter preference upon saving of the file (what David said about "leave existing ones alone" vs. "actively convert all cases"). But we're not really doing that. That should be a separate bug. But from my understanding, this bug is that we're just not using the line delimiter preference when users create new file/insert new line delimiters. So I'll look into that.
> An extra problem seems to be that our line delimiter preferences say we will > convert all line delimiters to the line delimiter preference upon saving of the > file (what David said about "leave existing ones alone" vs. "actively convert > all cases"). But we're not really doing that. That should be a separate bug. I have opened base bug 123287
*** Bug 107651 has been marked as a duplicate of this bug. ***
plugins affected: jst.jsp.core jst.jsp.core.tests wst.css.core wst.css.core.tests wst.dtd.core wst.html.core wst.html.core.tests wst.sse.core wst.xml.core wst.xml.core.tests AbstractDocumentLoader -modified createNewStructuredDocument(..) and added: String lineDelimiter = getPreferredNewLineDelimiter(iFile); if (lineDelimiter != null) structuredDocument.setPreferredLineDelimiter(lineDelimiter); -new method: private String getPlatformLineDelimiterPreference(IFile file) { IScopeContext[] scopeContext; if (file != null && file.getProject() != null) { // project preference scopeContext = new IScopeContext[]{new ProjectScope(file.getProject())}; String lineDelimiter = Platform.getPreferencesService().getString(Platform.PI_RUNTIME, Platform.PREF_LINE_SEPARATOR, null, scopeContext); if (lineDelimiter != null) return lineDelimiter; } // workspace preference scopeContext = new IScopeContext[]{new InstanceScope()}; return Platform.getPreferencesService().getString(Platform.PI_RUNTIME, Platform.PREF_LINE_SEPARATOR, null, scopeContext); } -deprecated getPreferredNewLineDelimiter() -new method: protected String getPreferredNewLineDelimiter(IFile file) { return getPlatformLineDelimiterPreference(file); } BasicStructuredDocument -make getLineDelimiter() & getPreferredLineDelimiter() call new method, getDefaultLineDelimiter() -new method: private String getDefaultLineDelimiter() { // specific preferred line delimiter if (preferedDelimiter != null) return preferedDelimiter; // no line delimiter has been used so just use platform's default String lineDelimiter = null; String sysLineDelimiter = PlatformLineDelimiter; String[] delimiters = getLegalLineDelimiters(); Assert.isTrue(delimiters.length > 0); for (int i = 0; i < delimiters.length; i++) { if (delimiters[i].equals(sysLineDelimiter)) { lineDelimiter = sysLineDelimiter; break; } } // no platform default so just use first legal delimiter if (lineDelimiter == null) lineDelimiter = delimiters[0]; return lineDelimiter; } -make setLineDelimiter(String delimiter) & setPreferredLineDelimiter(String probableLineDelimiter) call new method, setInitialLineDelimiter(String delimiter) -new method: private void setInitialLineDelimiter(String delimiter) { // make sure our preferred delimiter is // one of the legal ones if (Utilities.containsString(getLegalLineDelimiters(), delimiter)) { preferedDelimiter = delimiter; } else { if (Logger.DEBUG_DOCUMENT) Logger.log(Logger.INFO, "Attempt to set linedelimiter to non-legal delimiter"); //$NON-NLS-1$ //$NON-NLS-2$ preferedDelimiter = PlatformLineDelimiter; } } CSS/HTML/JSP/XML/DTD DocumentLoader modified getPreferredNewLineDelimiter(IFile file) String delimiter = ContentTypeEncodingPreferences.getPreferredNewLineDelimiter(contentTypeId); ==> if (delimiter == null) ==> delimiter = super.getPreferredNewLineDelimiter(file); return delimiter;
Okay, I've fixed this bug so that preferences for line delimiters will be followed for content type, and if "No translation" is selected, the eclipse platform default line delimiter (Preferences->General->Workspace->New text file line delimiter) will be used instead. I can't quite get the project preferred line delimiter to work due to a limitation in the info I have at document creation. However, once bug 101860 is fixed, this issue will automatically be fixed as well. In fact, once bug 101860 is fixed, content type-specific line delimiter preferences may be removed because project-specific line delimiter preferences should be specific enough for users. released for this week's 1.5 m6 build.
This bug is being moved to the "closed" state since it has been in the fixed state for a so long it is being assumed fixed, without explicit verification from the originator. If there is still a problem, in the most recent 1.5.x builds, please reopen or open another bug.
