Community
Participate
Working Groups
Using 3.4RC2. I got an IllegalArgumentException when calling CodeFormatter.format(int kind, String source, int offset, int length, int indentationLevel, String lineSeparator) method with kind equals CodeFormatter#K_JAVADOC, CodeFormatter#K_SINGLE_LINE_COMMENT or CodeFormatter#K_K_MULTI_LINE_COMMENT. The spec says that these values are valid kinds, hence should be accepted and format the regions inside the provided comment snippet.
*** Bug 241095 has been marked as a duplicate of this bug. ***
*** Bug 204091 has been marked as a duplicate of this bug. ***
Unfortunately, this issue cannot be addressed while the formatter writes plain text for block and javadoc comments...
Can someone please look at this for 3.8. This breaks the "format edited lines only" Save Action (bug 241095).
Ayush, please follow up, I have set the milestone to M4 so this is in the radar, but we may have to retarget it if needed as we understand how much work is involved.
(In reply to comment #5) > Ayush, please follow up, I have set the milestone to M4 so this > is in the radar, but we may have to retarget it if needed as we > understand how much work is involved. I am moving this to M5 so as to allow Ayush to focus on the code review and testing tasks associated with the null annotations work. If work on this gets completed we can always pull it up.
Moving to M6.
Ran out of time, Will look into this for M7.
(In reply to comment #4) > Can someone please look at this for 3.8. This breaks the "format edited lines > only" Save Action (bug 241095). Dani, I think this bug may be different. In the case of the save action, the kind is K_COMPILATION_UNIT, which is neither of the three that throw an IAE. I'll investigate a bit further and see if there's a simple fix for the save action (and also raise a new defect).
(In reply to comment #9) > (In reply to comment #4) > > Can someone please look at this for 3.8. This breaks the "format edited lines > > only" Save Action (bug 241095). > > Dani, I think this bug may be different. In the case of the save action, the > kind is K_COMPILATION_UNIT, which is neither of the three that throw an IAE. > I'll investigate a bit further and see if there's a simple fix for the save > action (and also raise a new defect). Do you have a better "kind"? We can pass K_UNKNOWN if that helps, as long as the result is good :-).
(In reply to comment #10) >[..] > Do you have a better "kind"? We can pass K_UNKNOWN if that helps, as long as > the result is good :-). I didn't mean the kind is wrong, I meant the kind being passed does not cause this bug (i.e. I don't see any IAE). So there must be a different bug in the formatter causing the breakage of the save action, and I'm trying to find that out. :)
Dani, after some investigation I don't think that bug 241095 is a duplicate of this one at all, as I mentioned above. Secondly, I think the current behavior is a consequence of wrong adaptation of regions inside JDT/Core (Scribe.adaptRegions()), which was intentionally introduced in bug 232768. However, that bug does not seem to request that changing anything inside a comment should cause whole comment be to formatted. It rather requests the formatter to format the whole comment when too much is selected. I don't know why the fix was done this way. Dani, since you were part of the discussion, do you have more context on what went on there? I fail to see why formatter should expand the region to the complete comment when even only a word changed inside.
(In reply to comment #12) > Dani, after some investigation I don't think that bug 241095 is a duplicate of > this one at all, as I mentioned above. Secondly, I think the current behavior > is a consequence of wrong adaptation of regions inside JDT/Core > (Scribe.adaptRegions()), which was intentionally introduced in bug 232768. > However, that bug does not seem to request that changing anything inside a > comment should cause whole comment be to formatted. It rather requests the > formatter to format the whole comment when too much is selected. I don't know > why the fix was done this way. Dani, since you were part of the discussion, do > you have more context on what went on there? I fail to see why formatter should > expand the region to the complete comment when even only a word changed inside. My bad guys... When rewritten the formatter to take into account comments in one pass, I missed 2 points (among others...): 1) that formatter should only replace with spaces. Hence, I thought it was better to rewrite the comment entirely formatted instead of only rewrite the spaces inside them (that was also easier... :-S) 2) the format might concern only one or several regions of the comment The design I used make now these 2 points really difficult to reach without rewrite a part or most of the code (peculiarly for Javadoc comments). Note two things though: - only point 1) is really hurting. When fixed, point 2) would become obvious - I already changed the design for line comments before I left, but I lacked time to do the same for block and Javadoc comments... I'd say that fixing that for Block comments should be accessible, typically by doing a similar change which have been done for line comments. However, for Javadoc comments, that will take a big amount of time and, if really needed, then should be targeted for next version, not this one... I can bring some help to understand the design of current implementation (but that was a long time ago...), however I'm afraid I won't have time to do more about this... Sorry for that :-( So, to workaround this issue, the solution was to select the *entire* block or Javadoc comment as soon as piece of it was select for formatting... If the rest of the comment was already formatted, user won't see any difference... If not, then it's sure that that can hurt.
(In reply to comment #13) > [..] > My bad guys... > > When rewritten the formatter to take into account comments in one pass, I > missed 2 points (among others...): > 1) that formatter should only replace with spaces. Hence, I thought it was > better to rewrite the comment entirely formatted instead of only rewrite the > spaces inside them (that was also easier... :-S) > 2) the format might concern only one or several regions of the comment Thanks for the explanation Frederic. :) > The design I used make now these 2 points really difficult to reach without > rewrite a part or most of the code (peculiarly for Javadoc comments). > > Note two things though: > - only point 1) is really hurting. When fixed, point 2) would become obvious > - I already changed the design for line comments before I left, but I lacked > time to do the same for block and Javadoc comments... > > I'd say that fixing that for Block comments should be accessible, typically by > doing a similar change which have been done for line comments. However, for > Javadoc comments, that will take a big amount of time and, if really needed, > then should be targeted for next version, not this one... Could you point me to the bug or code which fixed the line comment formatting? I'll try to emulate it for block comments, and will ask you for clarifications if needed. Not sure if I'll be able to , but I can try fixing the block comments atleast for now, and will take care of Javadoc in 3.9.
(In reply to comment #14) > Could you point me to the bug or code which fixed the line comment formatting? > I'll try to emulate it for block comments, and will ask you for clarifications > if needed. Not sure if I'll be able to , but I can try fixing the block > comments atleast for now, and will take care of Javadoc in 3.9. The only bug I remember about this is bug 234168. I don't think I used a specific one for line comments. Unfortunately, I didn't attach any patch to that bug when I do the changes for line comments :-( Hence, I'm afraid the only solution is to look at Scribe.java history. I hope it's still feasible despite the repository move from CVS to Git!?
(In reply to comment #15) > (In reply to comment #14) > > Could you point me to the bug or code which fixed the line comment formatting? > > I'll try to emulate it for block comments, and will ask you for clarifications > > if needed. Not sure if I'll be able to , but I can try fixing the block > > comments atleast for now, and will take care of Javadoc in 3.9. > > The only bug I remember about this is bug 234168. I don't think I used a > specific one for line comments. Unfortunately, I didn't attach any patch to > that bug when I do the changes for line comments :-( > > Hence, I'm afraid the only solution is to look at Scribe.java history. I hope > it's still feasible despite the repository move from CVS to Git!? While the history is still preserved, I'm not sure what to look for. The bug 234168 you mentioned is not fixed yet and I couldn't find any commit with that bug id or with any relevant comments. The last bug with comments "line comments" is bug 227043 but thats not the one we're looking for. Sigh. Probably I'll debug the code and see if I can find something.
(In reply to comment #16) > > While the history is still preserved, I'm not sure what to look for. The bug > 234168 you mentioned is not fixed yet and I couldn't find any commit with that > bug id or with any relevant comments. The last bug with comments "line > comments" is bug 227043 but thats not the one we're looking for. Sigh. Probably > I'll debug the code and see if I can find something. The central point for the modification was Scribe.printLineComment(int, int), but I finally found the precise moment I fixed this for line comments: bug 238210. Hope that this will give you more clues...
(In reply to comment #17) > The central point for the modification was Scribe.printLineComment(int, int), > but I finally found the precise moment I fixed this for line comments: > bug 238210. > > Hope that this will give you more clues... Thanks for digging it up Frederic. This will help. :)
Further discussion to be done on bug 241095
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.
There's not much chance of this being fixed. Hence marking accordingly.
