Community
Participate
Working Groups
Build Identifier: I20100426-0852 This is FUP of bug 59891. The fix for bug 59891 doesnt cover the corner case given in the attached file. Hence opening a new bug according to bug 59891 comment 41. the expected output should be abc.foo(abc.getString("sadldwdqd", "adadw", "qwdwwfr", "WFs"), abc.getString("sadlaawddwdqd", "adawqrdw", "qwdwqrfqwfr", "dwqFRFRQEWFs")); but isn't. Indeed, when the string arguments are small in length, we get the correct output. Reproducible: Always Steps to Reproduce: 1.Use the attached testcase and set the formatter profile to "Java conventions" 2.Press CTRL+SHIFT+F 3.See that the formatted code differs from the expected output given above
Created attachment 166204 [details] testcase
As I said in bug 59891 comment 41: > Yes, this is a corner case, where the second argument is over the max line, > hence the formatter enters into the "panic" mode and breaks the line as it did > before (i.e. the sooner as it can).
Created attachment 169835 [details] Zipped samples This bug seems generic enough for me to add the issues I outlined in bug 59891 , keeping only the obvious issues and not the things that account to taste. If you'd rather I open a separate bug for each, please let me know. I didn't really know how to provide the samples, went with a sample project. The attached is a zipped project containing three files : AcceleoFormatter.xml contains my exported formatter configuration, NewFormatterTest.java contains a set of samples that have been formatted with the new option turned on, and OldFormatterTest.java contain these very same samples, before the formatter came and wrecked things up. For one of the sample, reformatting after the new formatter did its thing doesn't give back the previous result, probably because of the NON-NLS tag. I'm not necessarily saying the old formatter was good for these samples, but it was less bad :p. Whatever the "old" and "new" formatter are doing on these, I believe they outline bugs in the new wrapping policy.
Ayush, may be can you have a look on this?
Still present in 4.4
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
If I repeat the steps to repro I get: abc.foo(abc.getString("sadldwdqd", "adadw", "qwdwwfr", "WFs"), abc.getString("sadlaawddwdqd", "adawqrdw", "qwdwqrfqwfr", "dwqFRFRQEWFs")); that is, the second call is kept in the same line as a whole (unless Bugzilla wraps it). Perhaps this is because the Java conventions now has a line width of 120. If I lower the max line width to 80, I get: abc.foo(abc.getString("sadldwdqd", "adadw", "qwdwwfr", "WFs"), abc.getString("sadlaawddwdqd", "adawqrdw", "qwdwqrfqwfr", "dwqFRFRQEWFs")); which seems quite like the desired behaviour. Am I missing something? Otherwise this may probably be considered fixed.
Yes, it must have been fixed with the formatter redesign. *** This bug has been marked as a duplicate of bug 303519 ***
Verified for Eclipse 4.13 M1 with Build id: I20190709-1800
