Author Topic: Pending changes in CodeCompletion (part 2)  (Read 9067 times)

Offline rickg22

  • Lives here!
  • ****
  • Posts: 2283
Pending changes in CodeCompletion (part 2)
« on: February 08, 2006, 04:16:56 am »
This is from a personal message exhange between me and Yiannis.

Quote from: mandrav
I think maybe we should just go for a ctags plugin. The system has become messy and not easy to shape up.
Or so I think...
Perhaps you're right, but that should go into parserthread only. We should do whatever takes us the least effort. Besides, the parsing itself is quite mature right now, and doesn't need too many modifications except changing the model from per-project to per-file.

What I would suggest, is refactoring the codecompletion part all over, right now it's too complicated to understand, full of cobwebs, obsolete data structuers, m_bool's, etc. We should refactor it so later we can adapt it to use CTags.

The "AI","reallyuseAI", etc. have me all confused. We should encapsulate them into a separate class and get rid of most of the accumulated junk.

I'd recommend making the following "standarized" wrapper routines:

a) bool ParseCurrentFile(); to parse the current file.
b) wxString GetTokenTypeFromCursor(); It would either be either a "POV" type or a class name.
c) vector<Token*> GetMatchingTokens(const wxString& TokenType); This would include both permanent and temporary tokens.
d) vector<Token*> FindMatches(vector<Token*> &ancestors,const wxString& prefix).
e) map<wxString, Token*> GetCodeCompletionItems(vector<Token*> &tokens);
f) ShowCodeCompletion(map<wxString, Token*> &items);

I think we should make a class called CodeCompleter, dedicated only to code completion and not parsing. Its owner could be the class Parser.
CodeCompleter would have, besides the above, the following methods (public):
h) CodeComplete();
i) ShowFunctionHints();
which would depend on the others. As you see, they can be called one after another without too much complication.

By modularizing and encapsulating the codecompletion functionality, we can extend them to make the next generation of the code completion plugin! :D

As a final note, CTags still doesn't parse local variables, so this refactoring effort wouldn't be lost. Plus, we COULD adapt the Token class to be a wrapper for the CTags ones...

My reason for refactoring the codecompletion part is that I need it to store the tokens per file and not per project. This would save us from the current memory problems with multiple projects, and would allow us later to use a database for storing the tokens.

---

So I guess that sums it all (except my idea to use the searchtree and a finite state machine for the parsing. I really hope CC achieves this point, but oh well).

Thank you all, it's been an honor to be part of this wonderful team! :D