Rename Assistant

[Olivier JG]

  On 10/21/2010 04:16 AM, David Nolden wrote:
> Of course the assistant could remember anything and do work-arounds,
> but the proper solution would be to simply not update the duchain as
> long as the renaming is taking place. Take a look at
> documentchangetracker.cpp, that is the component that decides whether
> the duchain will be updated or not. Maybe the assistant could tell the
> DocumentChangeTracker to prevent updating the duchain until a specific
> point.
>
> To me, this is how it could work:
> - The user starts editing a range which represents an existing use
>   ->  RenameAssistant tells the DocumentChangeTracker that the duchain
> should not be updated as long as a specific PersistentMovingRange is
> being modified (this would be the use range)
>   ->  RenameAssistant remembers the use that is being renamed, and
> starts listening, and shows a popup "Automatically Rename" which you
> can trigger with ALT+1
> - When the user has finished the renaming, he can push ALT+1 to apply
> the rename globally. If he leaves the range, the assistant disappears.
>
> Greetings, David
Well that can definitely make my life easier. This is what I ended up doing:

1. User starts editing declaration, I get it with getItemUnderCursor and 
store its identifier() and uses().
2. Any subsequent changes, I make sure we're still within/next to the 
range and update the new name (hmm... PersistantMovingRange /me hides 
range tracking code)
3. When accepted, the RenameAction goes through the uses and replaces 
them with the new name

It works, but although I didn't notice in my little tests, I imagine 
calling uses() could cause a pause in some cases, so I was thinking just 
don't show up in large scopes. Now I suppose I'll just store the 
declaration and leave the pause for the acceptance...

A question:
I notice SimpleRefactoring::startInteractiveRename() doesn't simply call 
uses() on the declaration and be done with it. Is just calling uses() 
enough?

-Olivier JG