Community
Participate
Working Groups
- new workspace - paste: /** * An internal class that does something * you really want to have done. * * @since 3.4 */ public class C { } - select the two first lines of Javadoc text - Ctrl+Shift+F => was: nothing changed => expected: text formatted into one line What's interesting is that it works when I either select the whole Javadoc, or when I remove the word 'something'.
This is a regression compared to 3.3.x and 3.4 M6.
I already warned that even after bug 102780 was fixed, clients still need to provide the entire javadoc source while using K_JAVADOC constant as it was done before. In this case, the DefaultCodeFormatter receive a kind of K_COMPILATION_UNIT | F_INCLUDE_COMMENTS with an offset starting at the beginning of the selection. The code formatter expects an offset at the javadoc start with a length of the entire javadoc comments, hence explain why it works if you select the entire comment... So, move back to JDT/Text to provide correct offset and length in this case...
Either I have to put the workaround back or JDT Core does this for us. Note that if this doesn't get fixed for 3.4 then the formatter's Javadoc should mention this. Moving back to JDT Core as the real bug is there.
Created attachment 99432 [details] Possible Workaround in JDT Text Any idea why the attached workaround doesn't work for multi-line comments? It does the same as for Javadoc: extend the region to cover the whole comment.
This seems to be (new) bug in the formatter: when I select a multi-line comment in the UI and then format, it also doesn't format it: Have <start selection> /* * An internal class that * does something you really want to have done. An * internal * class * that * does something you * really want to have done. An internal * class that does something you really want to have done. */ <end selection> It doesn't format the comment - same works for Javadoc comment.
See also bug 204091
In this case, the workaround is not enough complete: 1) the indentation level is not correct (always 0) 2) the entire source is provided and, as we format all the source, the last edit in the comment is optimized and also include characters after the end of the comment (typically the new line which is always rewritten). Due to filter added by bug 203304 fix, the edit reformatting the entire comment is rejected. I know point 2) would have been avoided if the comment formatter would not try to rewrite all the comments. I realize that it's not efficient and have some undesirable side effects. However, it's too late in 3.4 game to change this and we need to postpone this optimization for 3.5. The good news is that I have another possible optimization which will minimize the impact of this issue. The workaround may consist in passing only the entire comment source with offset=0 and length=comment length and use the comment kind instead of the K_COMPILATION_UNIT. In fact, exactly as it was done in 3.3. I'll attach a patch...
Created attachment 99985 [details] New proposed workaround for JDT/Text With this patch, everything works well. The only issue is that the entire comment is formatted even if only a part of it is selected, but it was still like that in 3.4M6. So, I guess this was a consequence of fix for bug 203304...
Dani, could you please review?
Patch is good. I moved some code a bit and adjusted @since tags. Filed bug 232054 for the problem in JDT Core.
verifying...
(In reply to comment #8) > Created an attachment (id=99985) [details] > New proposed workaround for JDT/Text > > With this patch, everything works well. I can not confirm that. It does not work for block and single line comments. Filed bug 232768. I'm marking this as verified fixed because the reported bug in comment #0 is indeed fixed.
Remove incorrect dependency
