UniString U( const string& Text )
{
UniString Result = U( Text.c_str() );
Result += '\0';
return Re <-- HERE
}
ReadClassStg
ReadClassStm
ReadConsole
ReadConsoleA
... (VERY long list)
int CodeCompletion::CodeComplete()
if (result.size() <= m_CCMaxMatches)
Yes - look below, the else tree will show a warning asking the user to increase the number of results. So not "nothing" is shown, but a warning.CodeIs this line correct?if (result.size() <= m_CCMaxMatches)
I've set it to 200 in the UI, but this value is ignored, as "/max/matches" is only read, never set.If that is true, then this is really a bug. :P
The config value set in the UI is "/max_matches" as far as I can see.
But again in my opinion this is broken, because the max_matches config variable should limit only the results shown in the listctrl, not the searching phaze.Well the point here is: How do you limit? The first, the last...?! Without an information provided to the user we will get a lot forum noise like "my function is not displayed" just because we silently strip the results. Here, instead, we show a warning so the user knows "There were many results, but we didn't know what to show.". I personally like this more... and that's why it is that way.
Of course if you prove me wrong or find a more clever solution - I am open for it.We can always add an item at the end - "number of matches reached the limit, please increase it to see all matches" or something like this.
You mean "at the end of 16000 items"? ::) Then you can also print it to the hidden debug log or the NullLogger... ;DOf course if you prove me wrong or find a more clever solution - I am open for it.We can always add an item at the end - "number of matches reached the limit, please increase it to see all matches" or something like this.
I just review the code, and see that:I've read that request description and the approach of presenting the last definitions first could also work. If I am thinking it correctly, the current function's variables are always going to be taken as the last in that context. And it would also be a pretty simple way of making big libraries (such as Windows, OpenGL, etc...) have low priority because they are commonly taken as a base to build custom code over them (and therefore are included BEFORE user definitions).Codeadding all the tokens to show, and sort the show items.int CodeCompletion::CodeComplete()
If a Token is a local variable(automatic variable), it will have Token->m_IsTemp==true.
So, maybe, we can firstly scan those tokens, and put them in the beginning of the codecompletion list.
I'm currently working on other part of CC, so it is great if you can help us. :)
Add to:
005252 (https://developer.berlios.de/feature/?func=detailfeature&group_id=5358&feature_id=5252)
If a Token is a local variable(automatic variable), it will have Token->m_IsTemp==true.This is possible, but requires modification to Scintilla (pending (http://sourceforge.net/p/scintilla/feature-requests/981/)).
So, maybe, we can firstly scan those tokens, and put them in the beginning of the codecompletion list.
wxString::app
Attached patch implements this.I'm afraid the last CC commit broke this. :-(
I'm afraid the last CC commit broke this. :-(Updated.
By the way, I have tried CC with your patch (in rev. 8901), and if you typesrc/plugins/codecompletion/codecompletion.cpp line 1012:Codeyou get 16 suggestions for append() (and Append()), one for each function overload. Is this intended behaviour?wxString::app
static const bool ignoreOverloads = false;
if (ignoreOverloads)
{
// check hashmap for unique_strings
if (unique_strings.find(tmp) != unique_strings.end())
continue;
}
When you tried sorting, did you also have to modify Scintilla to allow non-alphabetical ordering?No, I didn't.
you get 16 suggestions for append() (and Append()), one for each function overload. Is this intended behaviour?Yes, it is. Overloaded functions can have different arguments, return value and documentation, so in my opinion they should be displayed as separated items.
Overloaded functions can have different arguments, return value and documentation, so in my opinion they should be displayed as separated items.Maybe a more optimal way would be to only show overloads as separate items if you are in global scope and function argument completion is enabled.
I see. The autocomp list jumps the selection as you type by searching the list for the given context with a binary search. If the list is not alphabetized, the popup will often auto-cancel itself because it cannot find an entry (even though the entry exists). (I had just been curious to see if you had come up with a cleaner solution than mine.)QuoteWhen you tried sorting, did you also have to modify Scintilla to allow non-alphabetical ordering?No, I didn't.
Just thought I should mention, if you value a non-crashing Code::Blocks, do not apply this patch...I'm afraid the last CC commit broke this. :-(Updated.
if you value a non-crashing Code::Blocks, do not apply this patchWhich do you think cause the crash issue? The concurrently access to the tokentree?