Hello! This is not really a big problem but I noticed that the new call tip doesn't bold the current argument you are on
while typing; for example, in SVN 6992, if a function f(int arg0, int arg1, int arg2) exists,
typing f(1, 2
while staying on 2, arg1 will appear bolded which is quite nifty but the new calltip doesn't seem
to be doing that :\
Anyway, wonderful job nonetheless :)
I can confirm this on my self build rev 7071 (Windows,wx2.8.11), I will take sometime to check it. :D
it seems the code: codecompletion.cpp line around 1446
int start = 0;
int end = 0;
int count = 0;
int commas = m_NativeParser.GetCallTipCommas(); // how many commas has the user typed so far?
wxArrayString items = m_NativeParser.GetCallTips(maxCalltipLineSizeInChars);
std::set< wxString, std::less<wxString> > unique_tips; // check against this before inserting a new tip in the list
wxString definition;
for (unsigned int i = 0; i < items.GetCount(); ++i)
{
// allow only unique, non-empty items with equal or more commas than what the user has already typed
if (unique_tips.find(items[i]) == unique_tips.end() && // unique
!items[i].IsEmpty() && // non-empty
commas <= m_NativeParser.CountCommas(items[i], 1)) // commas satisfied
{
unique_tips.insert(items[i]);
if (count != 0)
definition << _T('\n'); // add new-line, except for the first line
definition << items[i];
m_NativeParser.GetCallTipHighlight(items[i], &start, &end);
++count;
}
}
if (!definition.IsEmpty())
ed->GetControl()->CallTipShow(pos, definition);
// Manager::Get()->GetLogManager()->DebugLog(_T("start=%d, end=%d"), start, end);
// only highlight current argument if only one calltip (scintilla doesn't support multiple highlighting ranges in calltips)
ed->GetControl()->CallTipSetHighlight(count == 1 ? start : 0, count == 1 ? end : 0);
}
the text between "start" and "end" will be highlight, but these interval was always wrong. :(
ok, debug a little, and I have found that the reason is:
recently, we use some pretty printer mechanism to do the call tip,
My test code is:
void f11111(int arg0, int arg1, int arg2);
f11111(1111111,)
I just enter a commas in the last line.
so the code works wrong
int commas = m_NativeParser.GetCallTipCommas(); // how many commas has the user typed so far?
wxArrayString items = m_NativeParser.GetCallTips(maxCalltipLineSizeInChars);
std::set< wxString, std::less<wxString> > unique_tips; // check against this before inserting a new tip in the list
wxString definition;
for (unsigned int i = 0; i < items.GetCount(); ++i)
{
// allow only unique, non-empty items with equal or more commas than what the user has already typed
if (unique_tips.find(items[i]) == unique_tips.end() && // unique
!items[i].IsEmpty() && // non-empty
commas <= m_NativeParser.CountCommas(items[i], 1)) // commas satisfied
{
unique_tips.insert(items[i]);
if (count != 0)
definition << _T('\n'); // add new-line, except for the first line
definition << items[i];
m_NativeParser.GetCallTipHighlight(items[i], &start, &end);
++count;
}
}
Here, items[0]="void f11111(int arg0, int arg1, int arg2)"
and commas calculated by "m_NativeParser.GetCallTipCommas();" is 1
But see the statement:
commas <= m_NativeParser.CountCommas(items[i], 1)) // commas satisfied
This will get false, because we pass a full string "void f11111(int arg0, int arg1, int arg2)", and CountCommas return ZERO. so we have No way to calculate the "start" and "end".
Maybe, the idea is: pass only the argument string which is "int arg0, int arg1, int arg2" to CountCommas() function, so the commas position should be satisfied.
Any ideas??? :D
I don't know if this is related, but the call tip apparently appears only after the first comma is entered, and disappears for good if the first comma is deleted.
ex: void uninitGL(HWND hWnd);
No tip: Tip: Tip disappears again and doesn't reappear:
If I revert the change in rev 6997 around the line 1888 in nativeparser
revert to:
if (token->GetFormattedArgs() != _T("()"))
{
wxString s;
BreakUpInLines(s, token->GetFormattedArgs(), chars_per_line);
m_CallTips.Add(s);
}
else if (token->m_TokenKind == tkTypedef && token->m_ActualType.Contains(_T("(")))
m_CallTips.Add(token->m_ActualType);
then, the highlight in call tip works fine. :D
Probably something like that should fix the bug: http://smrt.is-a-geek.org/codeblocks/patches/call_tip_highlight1.patch
The patch is tested only on a small example, so please test and report if there are problems with it.
If there are no problems in the next week, I'll commit it. :lol:
nice, one thing I should suggest is :
while (--pos > 0)
{
const int style = searchData.control->GetStyleAt(pos);
if ( searchData.control->IsString(style)
|| searchData.control->IsCharacter(style)
|| searchData.control->IsComment(style) )
{
continue;
}
const wxChar ch = searchData.control->GetCharAt(pos);
if (ch == _T(';'))
return;
this is a "backword" search, I think it should break on a "{".
so
if (ch == _T(';') || ch == _T('{') )
return;
and, for a consistent, the "(" we call open parenthesis instead of open bracket.
see: in the parserthread.cpp
namespace ParserConsts
{
const wxString space (_T(" "));
const wxString spaced_colon (_T(" : "));
const wxString empty (_T(""));
const wxString equals (_T("="));
const wxString hash (_T("#"));
const wxString plus (_T("+"));
const wxString asterisk (_T("*"));
const wxString comma (_T(","));
const wxString commaclbrace (_T(",}"));
const wxString dash (_T("-"));
const wxString dot (_T("."));
const wxString colon (_T(":"));
const wxString dcolon (_T("::"));
const wxString semicolon (_T(";"));
const wxString semicolonopbrace(_T(";{"));
const wxString semicolonclbrace(_T(";}"));
const wxString lt (_T("<"));
const wxString gt (_T(">"));
const wxString gtsemicolon (_T(">;"));
const wxString quot (_T("\""));
const wxString kw_C (_T("\"C\""));
const wxString kw_CPP (_T("\"C++\""));
const wxString kw__asm (_T("__asm"));
const wxString kw_class (_T("class"));
const wxString kw_const (_T("const"));
const wxString kw_define (_T("define"));
const wxString kw_undef (_T("undef"));
const wxString kw_delete (_T("delete"));
const wxString kw_do (_T("do"));
const wxString kw_else (_T("else"));
const wxString kw_enum (_T("enum"));
const wxString kw_extern (_T("extern"));
const wxString kw_for (_T("for"));
const wxString kw_friend (_T("friend"));
const wxString kw_if (_T("if"));
const wxString kw_elif (_T("elif"));
const wxString kw_include (_T("include"));
const wxString kw_inline (_T("inline"));
const wxString kw_namespace (_T("namespace"));
const wxString kw_operator (_T("operator"));
const wxString kw_private (_T("private"));
const wxString kw_protected (_T("protected"));
const wxString kw_public (_T("public"));
const wxString kw_return (_T("return"));
const wxString kw_static (_T("static"));
const wxString kw_struct (_T("struct"));
const wxString kw_switch (_T("switch"));
const wxString kw_template (_T("template"));
const wxString kw_typedef (_T("typedef"));
const wxString kw_typename (_T("typename"));
const wxString kw_union (_T("union"));
const wxString kw_using (_T("using"));
const wxString kw_virtual (_T("virtual"));
const wxString kw_volatile (_T("volatile"));
const wxString kw_while (_T("while"));
const wxString opbrace (_T("{"));
const wxString opbracesemicolon(_T("{;"));
const wxString clbrace (_T("}"));
const wxString tilde (_T("~"));
};
So, I suggest using the name "FindFunctionOpenParenthesis". :D
I just test your patch, and works flawless. great job!!!
I don't understand what is the problem here?
Can you show me a testcase where the code fails?
If you can't no changes to the code will be made!
I just do a research a little, and found that the "backward search" is expat started in the parentheses.
So, e.g.
This way, the "backward search" will stop at the open parenthesis of the a.f(. Let's say, the "backward search" stops at an un-balanced open parenthesis. So, this works OK normally.
But what dose the code:
if (ch == _T(';'))
return;
I suspect: In a function call statement, in the parentheses, does any one will write a ";" ?
I think these will be no semicolon there.
The semicolon is just used to stop the "backward search" in some cases to avoid the "backward search" goes too far.
So, if the code:
c.g();
a.f(arg0)|
or
for(...)
{
a.f(arg0)|
}
If the user mistakenly press the short cut to show tip, then, the "backward search" can safely be stopped at the "{" or ";" to save a lot of performance. Otherwise, the "backward search" will go to an earlier and wrong place.
Any ideas?
No, so maybe, we can leave it as it is.
We can add a counter and if the counter is greater than 1000 characters (for example), we stop the search :)
Yes, 1000 chars is quite enough.
Can you do some measurements, if this is really a performance problem?
add a timer to test it? and log out the time? :D
PS:
If we catch the new added char every time, then we can avoid counting the commas every time we do the calltip. :D I mean, we can only check the new added char, if it is a commas, then we can increase the previous value.