Community
Participate
Working Groups
Often when I try to override/implement a method the "cursor position" choice is missing in the dialog. I can't figure out the pattern of when it is or isn't offered, but it seems that it should ALWAYS be offered as an option.
After further testing it seems that the "cursor position" choice is missing if the cursor is between a comment ("//" or "/*") and any class member (field or method), even if the cursor is on a blank line.
*** Bug 114384 has been marked as a duplicate of this bug. ***
I just tested this in 3.2RC2 and the problem still exists.
A closely related problem to the missing 'cursor position' choice is that when this is offered as a choice the insertion often occurs in the wrong place, such as after a comment when the cursor was positioned before the comment. I also raised the severity of this bug because the inconsistent nature of the choice and insertion position of this valuable feature makes it almost useless in the general case (i.e. with insertions occuring any place in a file with typical Java '//' and '/**/' comments).
This bug is a major hassle, and renders this valuable and often used feature almost useless. 9 times out of 10 when I use override/implement the new code is inserted in the wrong place, so I have to go find it, and then move it to the correct place. I have reported this problem on 3 separate occassions, in various ways, in various bugs reports, with great detail as to how to reproduce it, but it hasn't been corrected in the last two upgrade cysles. As reported earlier, the problem is apparently due to this feature of eclipse not recognizing java comments correctly (// and /**), both when inserting the new code, and when determining whether or not to offer the "insert at cursor" choice. Am I the only one having this problem? Perhaps the original name of this bug was misleading as to its seriousness. As such, I changed the name of this bug to better reflect the natuire of the bug (bad code insertion).
*** Bug 168796 has been marked as a duplicate of this bug. ***
See also bug 215982 for some simple broken scenarios.
*** Bug 100135 has been marked as a duplicate of this bug. ***
You are right, we are promising too much here. Our code rewrite infrastructure isn't as fine granular that we can specify between which comments to insert. The only granularly is between which members. Changing is a bit of work that doesn't has priority and has to wait. So I decided to remove the 'At cursor' insertion point an replace it with the 'After xy' that corresponds to the cursor position. I know that's probably not helping you much, but should help avoid other confusions. The workaround is to use code assist, which can also insert overridden methods.
Created attachment 99250 [details] patch Patch removes the 'At cursor' insertion point and replaces it with the corresponding 'Insert after x'
Dani, can you review?
Patch is good. I would prefer 'First/Last member' and to propose to insert after the method when the caret is inside a method (currently it's 'Last').
patch released with the 2 changes suggested > 20080508
marking as fixed.
This bug is NOT fixed nor is it resolved! All you did was put a bandaid on it, which is fine for now and understandable given your explanation. However, the bug that was reported is NOT fixed nor resolved. PLEASE leave this bug open so that I won't have to go through this whole tra-la-la again. This has been dragging on for years now in various forms and missteps. If need be, reclassify it as a feature request, but don't just drop it. --jon.
I understand what you say, and I also hesitated to set it to 'FIXED'. Problem is: the 'insert at cursor position' doesn't exist anymore. This bug is either invalid or fixed. You choose. If you want the feature 'insert at cursor position' back, then file a new enhancement request. I think that's the cleanest way.
I changed the severity to "enhancement". That way the trail of tears as well as the interim bandaids can be preserved for posterity. --jon
I prefer a new bug. This one already contains multiple comments dealing with the old state of the feature.
I filed new bug request bug 231265 for this. Please add additional comments there.
