Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 343821

Summary: Replacing text does not update search matches for files that link to the same OS resource
Product: [Eclipse Project] Platform Reporter: Raksha Vasisht <raksha.vasisht>
Component: SearchAssignee: Dani Megert <daniel_megert>
Status: VERIFIED FIXED QA Contact:
Severity: normal    
Priority: P3 CC: daniel_megert, markus.kell.r
Version: 3.7Flags: markus.kell.r: review+
Target Milestone: 3.7 RC1   
Hardware: All   
OS: All   
Whiteboard:
Attachments:
Description Flags
Fix none

Description Raksha Vasisht CLA 2011-04-26 07:18:59 EDT 
Build :  I20110425-1800 (not a regression for M7) 

Create a test project with 2 text files linked to another(B linked to A) in a fresh workspace

//A.txt
test

//B.txt
test

Select 'test' and Search->Text-> Workspace
-> Shows 2 entries A & B as matches in Search view

1) A.test-> Replace Selected...-> 'THING' 

=> replaces in both files but highlights only 4 characters in B.text, and also
does not update the search view for B.txt match.

2) Now drill down to B#THING in search view and right click , 'Replace Selected...' with 'AAAAAA'

The replace happens only for B.txt and when you go to A.txt , it prompts for replacing the text there as well. On clicking OK, the text is replaced but the highlighting is not proper(highlights prev text size) and also search view is not updated by the replace action.

3)  Same problem as 2 with Replace All... for both selections (ie even if A->text is selected, only text in B is replaced)

I'm guessing the Replace refactoring also does update the search view ( I see that in the preview) and not sure who takes care of the highlighting of the replaced text.
Comment 1 Dani Megert CLA 2011-04-26 08:27:46 EDT 
> ... and when you go to A.txt , it prompts for
> replacing the text there as well.(In reply to comment #0)
That's the expected behavior (assuming you did not save A.txt before).
Comment 2 Markus Keller CLA 2011-04-26 12:08:36 EDT 
To complete the support from bug 320533, the ReplaceRefactoring should also
- remove the skipped secondary links to matches from the search result
- refresh the secondary files in the workspace
Comment 3 Dani Megert CLA 2011-05-04 10:01:01 EDT 
A complete fix would be too expensive and would not be local to the replace refactoring but also touch the view updating (search for file matches with same link target). In addition, once the view is involved, 'Undo' becomes problematic as the refactoring doesn't know what the view did. Actually, this is already know an issue when replacing "normal" matches.
Comment 4 Dani Megert CLA 2011-05-04 10:05:13 EDT 
Created attachment 194717 [details]
Fix

The attached patch fixes the case where the selected/all matches to replace contain all the links pointing to the same target. If that's not the case then the view will still be out of sync.

This patch also cleans up some code. Relevant part of the changes are in:
- ReplaceRefactoring.SearchResultUpdateChange.getMatches()
- ReplaceRefactoring.isAlreadyCollected(FileMatch)
Comment 5 Dani Megert CLA 2011-05-04 10:05:30 EDT 
Markus, OK for RC1?
Comment 6 Markus Keller CLA 2011-05-05 06:30:44 EDT 
+1 for RC1. Released ReplaceRefactoring.java to HEAD with a few minor changes.
Comment 7 Raksha Vasisht CLA 2011-05-16 06:52:47 EDT 
Verified for 3.7RC1 with  I20110514-0800.