DocumentChange unpractical for signature assistant

David Nolden zwabel at
Tue Jul 6 11:16:20 UTC 2010

You anyway need the exact range that you want to replace, so I don't see the
problem specific to DocumentChange. You can simply read the old text from
the range out of the editor. That somewhat defeats the purpose 'safety', as
it might happen that you replace _anything_. Your idea with the AST would be
the best, but might be some work. It's the only way to reliably get the
whole range that needs to be replaced.

Greetings, David

Am 06.07.2010 12:25 schrieb "Milian Wolff" <mail at>:

Hey there,

while trying to revive the SignatureAssistant for changes in the return
I saw (again, had the same problems with constness) that DocumentChange is
totally unpractical here.

The thing is that for safety reasons we need to _exact_ old string and then
replace that or parts of it with changes. Sounds nice. But: We don't access
the acutal written document, hence only "guess" how the old signature looked
like and try to replace it. Meaning:

void foo() const;

=> works (one space, then const)

void foo()\tconst
=> won't work and similar

With return type it's even harder, since one does not now whether we have:

returntype ClassName::methodName() {}

returntype SomeNamespace::ClassName::methodName() {}

returntype someTypeDef::ClassName::methodName() {}

and so forth.

The parameters at least know the range they replace (the Function context)
ignore the old text. For the other parts this is not possible. So what
we do here?

1) get AST for document and replace on that, might be slow - advantage:
completely safe to replace

Since that's API/code wise easy to implement, I'm actually tempted to use
for now.

2) only get the line of the signature to change and use regex to find ranges
for DocumentChange, i.e.:


might need to handle comments though. That would be "fast", but I don't know
what the best way is to get the string for a line in a document, considering
it might not yet be opened. Ideas? I could just create a KateDocument but
might do too much, do we have something else?

Milian Wolff
mail at

KDevelop-devel mailing list
KDevelop-devel at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the KDevelop-devel mailing list