Moving stuff for include-completion to kdevplatform

[David Nolden]

Am Montag 03 August 2009 14:18:46 schrieb Milian Wolff:
> Hi again :)
>
> Cpp contains a lot of stuff which other language plugins could take
> advantage of. Right now I want to implement autocompletion for includes
> in PHP.
>
> What I think would be useful:
> - moving cpp/includeitem.h to kdevplatform:
>    * would language/codecompletion be a sane place for that? Esp.
> considering that this header is used e.g. in some Cpp specific quickopen
> stuff. Maybe utils is a better place?
Should be ok moving that into kdevplatform, but IMO it needs to go into some 
utils directory. Generally, there is too much utility-stuff in kdevplatform 
that has been moved in from C++, and made some kind of API, even though it was 
basically just designed to be a C++ specific internal thing. For example all 
the CompletionTreeItem stuff. Yes it is good to reuse that code, but it would 
need some review and redesign, instead of just copying the stuff over, that's 
why this does not give me such a good feeling.

> - moving IncludeFileCompletionItem from cpp/codecompletion/items.h:
>    * this should really go to language/codecompletion.
>    * except for the execute() method it looks language independent. It
> should just be pure abstract or virtual.
Should be ok.

> - moving IncludeNavigationContext to kdevplatform:
>    * again - where to put this? language/util ?
>    * we also should take a look at what can be reused and what not. Esp.
> the environment file info (number of declarations etc.) should be
> language dependent. Macros e.g. are Cpp specific. Just having the html()
> method virtual should be enough imo so it can be subclassed for language
> where required.
>    * pickContextWithData() contains the lines:
>
>      if(!ctx->parsingEnvironmentFile() ||
> ctx->parsingEnvironmentFile()->type() != KDevelop::CppParsingEnvironment)
>        continue;
>
>      so that generic IncludeNavigationContext has to be a template?
No.. this is just for filtering out the non-c++ top-contexts, which is fairly 
trivial. It could be moved into a virtual function.
>
> Everything else should imo stay as it is and be reimplemented on a
> per-lang basis. Esp. getting reasonable list of include files is imo
> highly lang dependent. For PHP it has to work for remote projects, maybe
> honor a per-project setting for custom include paths etc. etc.
>
> I can work on the stuff above, but want some input first so I don't mess
> things up...
Please, just make sure that you test everything properly, and don't introduce 
regressions to C++ support, as I don't have that much time to hunt down new 
bugs, and want to concentrate on fixing the already existing ones instead. ;-)

Greetings, David