Community
Participate
Working Groups
in i0420 - load org.eclipse.platform from CVS and check out revision 1.56 of Main - set the code formatter preferences to the core settings found at http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/platform-core- home/documents/core_formatting.xml - Set the "Compiler->Advanced->Usage of non-externalized strings" to Error - format Main - notice that many methods (e..g, getInstallLocation) formatted incorrectly (the method headers are not indented and directly follow the preceding method) - if you change the Compiler setting to ignore, the class formats correctly.
Created attachment 9869 [details] test case for the formatter I don't know what is going on in the editor. The formatter itself has no problem to format that code. But inside the editor the code is all mixed up after the formatting.
Move to JDT/Text. What happens when the code contains errors (like non NLS string literals). The code formatter doesn't care about these errors. I attached a test case before formatting (Main_in.java) and after formatting (Main_out.java). You can check that the formatting inside the editor is different from what I get from the code formatter. I use the same edits. I will also attach the code after formatting in the java editor.
Created attachment 9870 [details] wrong result after applying the edits on the document I wonder if this is not a bug relative to the positionning of markers in the compilation unit. Jeff says that if no errors are returned (ignore non-nls string literal) then it works fine. From a code formatter point of view, the text to format is identical, but I think it is different for you to apply the edits on the document.
I raise the severity, because this seems to be a severe problem with applying edits on a document that contains marker. Let me know if I can help.
I take it back on my side for now. It seems that the number of edits is different if the file contains errors or not. I don't see why, but this is the case. I am investigating.
In fact, the bug comes from the code formatter. The problem is that compile errors can change the file ignoreFurtherInvestigation on the method declaration and constructor declarations. In this case the code formatter jumps above them and this leads to inconsistent edits that are therefore impropertly applied to the document. So the document is not responsible. I am investigating what can be done in the code formatter to fix this issue.
I think the fix is to use the default compiler options in the code formatter when building the compilation unit declaration used by the visitor. The code formatter only cares about syntax problems, but it doesn't care about errors in the code like non-nls strings. I am working on a fix.
Fixed and released in HEAD. Regression test added.
Verified for 3.0M9
