#19 Search and replace in selection does not always work

[Anonymous]

Hi,

I might have found a bug :
How to repeat :
- Create a Find and replace simple macro
- Tick the "Search in selection" box
- Run the macro

What happens:
Nothing at all

Debugger:
--Executing command: Find abc
--After command, cursor at: Line 122, Column 1
--After command, the selection pivot point is at: Line 132, Column 1
--Finished executing macro:

What is expected: replacement obviously :)

Notes:
- The lines shown in the debugger are 7 lines wrong (my selection was from 129 to 138)
- If I select by mouse or Shift+keys, i can reproduce the bug, however selecting with ^A works normally

Thanks for the great plugin !
Cheers
Tug

[Anonymous]

Update:
If I select larger chunk of code than were i want to replace, it will eventually find pieces of what i want and replace it.

Update 2: Can't reproduce the bug in a brand new workspace (same eclipse, Kepler 4.3.2 with CDT plugin distribution)...

[Anonymous]

Update 2:
The selection in which the macro is applying the F&Replace alway seems to be at a lower (random ?) number of lines than the actual selection.
Thus this happens when trying to F&R at one of the first line (Out of scope error):
http://pastebin.com/8Mex303w

[Anonymous]

Update 3:
Ok I finally found the cause of the bug: Code folding

Eclipse code folding induces a virtual shift in the selected text which apply the macro at other lines than the one you selected.

It seems that some kind of protection features does not apply the macro if the lines the macro tries to apply to do not overlap with the ones you really selected (i.e you have to select a big chunk of code to have SOME lines modified)

Quick fix: Click "Expand all" in code folding (right click next to line numbers) before applying the Search in selection macro.

You might never even read this but this could be useful to at least mention as known bug if you don't plan on fixing it :)

Cheers
Tug

[Ernest]

Okay Tug, thanks for the report. I don't know if I'll have time to look at a fix for this in the near future, but I appreciate you tracking down the scenario.

[Ernest]

I have pushed out version 0.4.6 to fix this. The find utility I'm using internally seems to require widget coordinates (ignoring folding) as the start position, but absolute coordinates as the bounds of the find. I think I have it working better now.

[Anonymous]

Oh wow you actually fixed it =)
Thanks for the quick support !

Tug