DocumentChange unpractical for signature assistant

[David Nolden]

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 milianw.de>:

Hey there,

while trying to revive the SignatureAssistant for changes in the return
type,
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)
and
ignore the old text. For the other parts this is not possible. So what
should
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
that
for now.

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

^\s*\bOLDRETTYPE\b\s+(\w+)::FUNCNAME(.*)\s*(const)?\s*{?$

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
that
might do too much, do we have something else?

Bye
--
Milian Wolff
mail at milianw.de
http://milianw.de

--
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/20100706/022fe303/attachment.html>