Rename Assistant

[David Nolden]

PersistentMovingRange is simpler in the sense that you don't need to listen
to any signals from MovingInterface etc.. Adding a bool flag should be fine.

About deciding when to offer the assistant: You can catch local declarations
by checking "decl->context()->kind() == DUContext::Other", and
function-arguments with "...->kind() == DUContext::Function", and that
should be all places where this should be allowed.

Unless the assistant causes grave problems, you can commit it.

Greetings, David

Am 27.10.2010 11:53 schrieb "Olivier JG" <olivier.jg at gmail.com>:

Attached are updated patches for the rename assistant. Some questions
below..


>
> I don't exactly understand what you mean by this. It is possible to
> tell MovingRange to exten...
I added a bool option to PersistentMovingRange, but perhaps I should expose
the actual flags?
Perhaps I should just use MovingRange... unless there's another reason to
use PersistentMovingRange? The rename assistant is gone when the document is
closed..


>
> For renaming of local variables, uses() is enough.
Well that's simple enough then. I now don't offer to rename anything that
opens a context, or is a forward declaration, with an exception for
functions that aren't class members. Let me know if it should be something
else.

Pending an answer on MovingRange vs PersistentMovingRange, and if no one
takes issue with the patches, I'll commit this.

-Olivier JG

--
KDevelop-devel mailing list
KDevelop-devel at kdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20101028/1ce42c24/attachment.html>