Rename Assistant

David Nolden zwabel at
Wed Oct 20 20:16:22 UTC 2010

2010/10/18 Olivier JG <olivier.jg at>:
>  @David Nolden?
> I took a look at the assistant architecture a bit yesterday, to see the
> possibilities for a renaming assistant.
> Here's how things look to me now:
> 1. User makes a change (either insert or remove)
> 2. Code Assistant makes a new assistant
> 3. Assistant takes a look at what happened (before the declarations are
> updated) and decides what to do
> 4. Parser finishes its business and updates the DUChain
> The only thing that stops this from being a walk in the park is that the
> user is unlikely to want to perform a rename every time he adds/removes a
> character to his variable (although I must say, making that happen
> automatically could be awesome, though probably too prone to breakage to
> consider). In order to get past that the rename assistant would probably
> have to extend its lifetime beyond a single change, and so wouldn't be
> recreated on every change. It could then, with a bit of work, track the
> changes that happen by comparing the given range of change, and offer the
> rename accordingly.
> Then comes the more sticky issue: the signature assistant gets to look at
> every change, but right after that, the DUChain does too. Once the first
> change is done and the second rolls around, you get a different declaration
> (one that has no uses, obviously), and the useful declaration is gone. In
> order to avoid having to study the DUChain too extensively, I thought I'd
> ask... Can the RenameAssistant save the original declaration and use it for
> the rename, or would it get deleted/broken/make-bad-things-happen?
> Am I seeing this right? Any insight on this?

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

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

More information about the KDevelop-devel mailing list