Rename Assistant

David Nolden zwabel at googlemail.com
Tue Oct 26 12:16:22 UTC 2010


2010/10/21 Olivier JG <olivier.jg at gmail.com>:
>  Writing to send in the current iteration of the RenamingAssistant
> (attached). It doesn't yet do the DUChain stopping for a couple reasons:
> 1. I have to create a new and updated PersistentMovingRange when the changes
> are adjacent to it (ie, decl -> declRenamed)
I don't exactly understand what you mean by this. It is possible to
tell MovingRange to extend the range on adjacent edits, we could add
such an option to PersistentMovingRange as well.

> 2. The only advantage at the moment is delaying the call to uses() until
> after the assistant is called
> 3. See known issue #3
>
> Known issues include:
> 1. Doesn't rename both sides (definition/declaration) of a function's name
> or arguments (uses() doesn't give me those)

I think it's questionable whether we should even _try_ to do this.
There is much more complex logic required when renaming something else
than a local variable. For example for classes, you need to consider
constructors/destructors, forward declarations in many different
places, etc. For functions, you need to consider
declarations/definitions, argument-matching, and possible multiple
declarations in different places. That's what the interactiveRename
stuff does differently: It has to do a global search for the real
global uses (updating the duchain for specific files as required), and
then it has to apply more complex renaming schemes. Also, since the
results are global, it is crucial that the user gets a preview of the
changes before applying them, so I think for such global renaming, we
simply shouldn't use the assistant.

For renaming of local variables, uses() is enough.

> 2. I've seen the range for the declaration given by itemUnderCursor be
> really strange in certain situations (which means you won't be offered a
> rename)
> 3. The DocumentChangeSet won't apply (gives errors) until the document has
> been reparsed, so the assistant waits until then to offer (would be really
> nice to be offered instantly)
It will only give errors when you give it invalid replacements,
probably the problem is the range which the user is editing, you could
simply leave that one out, as the user has already changed it
manually.

Greetings, David




More information about the KDevelop-devel mailing list