Community
Participate
Working Groups
Consider a class C and character | marking where the cursor is: public class C { static void m() { metall|llll(); } static void metallllll() {} } Activate inline renaming, then press CTRL-Space to activate content assist: Press Left, l, Left, l, Left, l. If done correctly, content assist popup window stays visible the whole time. Hold down Left-Control and the highlighted text marker goes 3 characters past the end of the name of the method. Bug 90769 may be the same issue.
Also present in Eclipse IDE for Java Developers Version: Kepler Release Build id: 20130606-0932
This works for me using 4.3 RC4 [1] on Windows 7, but maybe I'm not using the right steps. [1] http://download.eclipse.org/eclipse/downloads/drops4/S-4.3RC4-201306052000/
Created attachment 232683 [details] Picture taken after executing the steps from comment 0
Created attachment 232694 [details] Test project for repro Maybe something in project settings that causes it.
Created attachment 232695 [details] Animated Gif showing the bug Still occurs in Eclipse SDK Version: 4.3.0 Build id: I20130605-2000 Here's a recording of the bug being triggered in the test project.
Reopened with more information.
This still reproduces for me in Kepler package eclipse-java-kepler-R-win32.zip, Build id: 20130614-0229, when I switch to a brand new workspace, import the test project from attachment 232694 [details], open class rename.content.assist.C and repeat the steps in it, on the SECOND and subsequent tries. Dani, I think inline rename is not active in your screenshot because there's no rectangle around the first name and the names are different. The error condition exists only while a single rename operation and a single content assist window are active at the same time, each time the content assist window closes and reopens the overwriting resets to correct length hiding the mismatch. Please try with these steps, thanks.
Not sure what I did, but now I can easily reproduce using R4.3. Broken since the feature exists (2.1). Noopur, please have a look. I suggest you start your investigation in 'AbstractJavaCompletionProposal'.
Example: class T { { metal(); metal(); metal(); } } Use Ctrl+1, 'Rename in file' on first "metal" in the above example. Place cursor at meta|l and press Ctrl+Space. Type 'l' and then press Ctrl. The highlighted text extends to 3 chars after cursor instead of 1 char. ----------------------------- In AbstractJavaCompletionProposal.validate(IDocument, int, DocumentEvent), we 'adapt replacement range to document change' and update the replacement length based on delta change. The delta calculated there is for the entire document, from the merged document event. (The merged event is created at CompletionProposalPopup.fFilterRunnable.new Runnable() {...}.run() by TextUtilities.mergeProcessedDocumentEvents(fDocumentEvents)). In case of rename refactoring where the text appears at more than one location in the document, the delta includes the changes at all the locations. In the example, delta is 3 instead of 1 due to 3 occurrences of "metal". AbstractJavaCompletionProposal.createStyleRange(ITextViewer viewer) uses replacement length set above to get the length of highlighted text, which comes as 3 instead of 1. (int length= getReplacementOffset() + getReplacementLength() - modelCaret;) Ideally, the 3 highlighted letters should be shown as 1 letter each at the respective occurrences of the text being renamed or only 1 letter at the position after cursor. But we do not have any information about the rename refactoring being preformed here. Dani, please suggest what could be done.
(In reply to comment #9) > Ideally, the 3 highlighted letters should be shown as 1 letter each at the > respective occurrences of the text being renamed or only 1 letter at the > position after cursor. No, it should only highlight where we invoke content assist and then replace the correct range. > But we do not have any information about the rename refactoring being > preformed here. > Dani, please suggest what could be done. The linked mode model might provide the info.
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. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. 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.
