Community
Participate
Working Groups
final String happy = "string is a happy place" + "string is a happy place" + "string is a happy place"; //$NON-NLS-1$//$NON-NLS-2$//$NON-NLS-3$ becomes final String happy = "string is a happy place" + "string is a happy place" + "string is a happy place"; //$NON-NLS-1$//$NON-NLS-2$//$NON-NLS-3$ This breaks the externalized strings mechanism provided elsewhere in Eclipse. Non-externalized strings are both recognized as a quick fix and a compiler setting. They are requirement for all code written as part of Eclipse. This makes the formatter unfit for developing Eclipse code.
Wasn't this fixed in the old formatter by just refusing to wrap such lines? This is a major regression.
You can always remove all wrappings.
Wrapping lines is one of the main reasons we want to use the formatter - so that the code becomes readable at the default line width. We want to use the default Java formatter settings and right now they're broken because of this bug.
Let me clarify something. The usage of //$NON-NLS-<n>$ is clearly not a standard way to NLS code in Java. To fix this, I need to introduce a hack in the code to support the way Eclipse does it. What about a request to support another tag? What will happen if the NLS tag is changing? There are bugs to chnage the format of the tag.
Eclipse already has hacks to support it in the JDT compiler settings. The absence of such a tag can result in a warning or an error. Supporting it in the code formatter would be consistant behaviour and eclipse users (ie: us :) already rely this behaviour from previous releases.
If this is your concern, then introduce a preference that defines such a string. By default, the NLS string format would be: "$NON-NLS-[:number]$". But, this would be an additional feature. As Nick points out, the current functionality is a regression. Any estimated time until this will be fixed?
No. I need to investigate how to do it without losing all the line wrapping functionality.
*** Bug 54013 has been marked as a duplicate of this bug. ***
We want to refuse to wrap such lines. Workaround is to manually fix the code so that it wraps happily. Time permitting for M9, as non prioritary.
*** Bug 53513 has been marked as a duplicate of this bug. ***
*** Bug 44653 has been marked as a duplicate of this bug. ***
Manually fixing up formatter errors is a non-starter. The UI team cannot use the formatter until this bug is addressed.
To answer to comment 6, this is not $NON-NLS-[:number]$, but it would be: //$NON-NLS-[:number]$ I will add an option, but the NLS tag will be hardcoded for now. I should be able to release a patch for next integration build.
Fixed and released in HEAD. Updated the formatter regression tests. No options is provided. NON-NLS tags are left on the line that contains the string literals. This takes precedence of other options. If users want other options to be respected, they will have to fix the code manually. The code formatter won't do comments refactoring to respect all options.
*** Bug 58999 has been marked as a duplicate of this bug. ***
*** Bug 39465 has been marked as a duplicate of this bug. ***
Verified for 3.0M9
