<p>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.</p>
<p>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.</p>

<p>Unless the assistant causes grave problems, you can commit it.</p>
<p>Greetings, David</p>
<p><blockquote type="cite">Am 27.10.2010 11:53 schrieb "Olivier JG" <<a href="mailto:olivier.jg@gmail.com">olivier.jg@gmail.com</a>>:<br><br>Attached are updated patches for the rename assistant. Some questions below..<p>
<font color="#500050"><br>><br>> I don't exactly understand what you mean by this. It is possible to<br>> tell MovingRange to exten...</font></p>
I added a bool option to PersistentMovingRange, but perhaps I should expose the actual flags?<br>
Perhaps I should just use MovingRange... unless there's another reason to use PersistentMovingRange? The rename assistant is gone when the document is closed..<p><font color="#500050"><br>><br>> For renaming of local variables, uses() is enough.</font></p>

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.<br>

<br>
Pending an answer on MovingRange vs PersistentMovingRange, and if no one takes issue with the patches, I'll commit this.<br><font color="#888888">
<br>
-Olivier JG<br>
</font><br>--<br>
KDevelop-devel mailing list<br>
<a href="mailto:KDevelop-devel@kdevelop.org">KDevelop-devel@kdevelop.org</a><br>
<a href="https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel" target="_blank">https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel</a><br>
<br></blockquote></p>