Developer forums (C::B DEVELOPMENT STRICTLY!) > CodeCompletion redesign
CC plugin interface redesign
dmoore:
--- Quote from: Alpha on November 07, 2013, 06:13:46 am ---By the way, you can 'cheat' a bit to prevent the calltip from flashing as you press left/right arrow keys. (Edit: Just make sure to process cbEVT_SHOW_CALL_TIP afterwards with either the actual results, or an empty string vector so CCManager knows to cancel it.)
--- Code: ---Index: PythonCodeCompletion.cpp
===================================================================
--- PythonCodeCompletion.cpp (revision 434)
+++ PythonCodeCompletion.cpp (working copy)
@@ -511,6 +507,11 @@
cbStyledTextCtrl *control=ed->GetControl();
m_state = STATE_CALLTIP_REQUEST;
RequestCallTip(control,argsStartPos,ed->GetFilename());
+ if (control->CallTipActive()) // Probably ours, so return the last know definition so it does not cancel while we recalculate
+ {
+ sv.push_back(m_ActiveCalltipDef);
+ argsPos = m_argsPos;
+ }
return sv;
}
return sv;
--- End code ---
--- End quote ---
I will incorporate that. thx.
--- Quote ---(I think your plugin sometimes returns " " as a calltip; probably it is the plugin's job, not CCManager, to filter that.)
--- End quote ---
Yeah, I noticed the empty calltip would pop up occasionally. Maybe that's what is coming from the jedi completion lib because I don't think my code does this. I will try stripping it and see if that fixes the issue.
frithjofh:
hi everybody,
I was following this thread for some time now. and I keep stumbling on the same question:
shouldn't all this code completion stuff be separated in two things?
if I understand right one big block of this is the actual analysis of the code and parsing it into some kind of searchable structure, lets call it the TREE. this is dependent on the language. it is focused on analysis and is somewhat abstract. by all means a very basic and low level work and part of c::b.
the other part is putting this information to use for the developer. here in this special case for code completion. this is rather like using only a tiny part of the underlying information and potential of the TREE.
this separation is illustrated too by the way there exists the symbols tab inside the manager panel. this has functionally nothing to do with the code completion pop up really...
and there are other plugins that could leverage the information of the TREE: the code refactoring plugin to edit individual symbols, the search plugins, which could use it to search for entities by type (variables, members, functions, classes) instead of only by name, the statistic plugin... and I bet a bunch more of functionalities inside of c::b, plugin or not.
so, should this not better be separated? the TREE as a base part of c::b, parsing code for everybody free to use the information, maybe not even as a plugin at all, and then the actual code completion as a plugin?
regards and sorry in advance if this post is only boring/annoying the devs...
frithjofh
Alpha:
--- Quote from: frithjofh on November 09, 2013, 03:17:47 pm ---shouldn't all this code completion stuff be separated in two things?
--- End quote ---
On the longest term, that would have the greatest flexibility. However I currently do not have the skill to create a language independent AST. Maybe that is something for the next iteration of the CC interface... it is quite a bit more complicated than I can easily visualize.
oBFusCATed:
Interested people could look at kdevelop's source code, I think they have something like this already implemented.
darmar:
Hi,
I am playing with this cc_interface branch currently, and found a feature or a bug, but I am not sure.
--- Code: --- int main ()
{
int i = my_function(undefined_variable);
}
--- End code ---
If I keep the mouse over "undefined_variable", a call-tip for "my_function" will be showed. I think, the function CodeCompletion::GetTokenAt is called at first, but because this function returns an empty vector, the function CodeCompletion::GetCallTips is called.
Is it a feature? If yes, I should find a workaround for FortranProject plugin.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version