zwabel at googlemail.com
Thu Oct 28 11:19:35 UTC 2010
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.
Am 27.10.2010 11:53 schrieb "Olivier JG" <olivier.jg at gmail.com>:
Attached are updated patches for the rename assistant. Some questions
> 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
> 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
Pending an answer on MovingRange vs PersistentMovingRange, and if no one
takes issue with the patches, I'll commit this.
KDevelop-devel mailing list
KDevelop-devel at kdevelop.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the KDevelop-devel