Hello, all.
I've make a patch, which improves codecompletion plugin toolbar functionality and speeds up switching editors.
1. Now in the plugin options dialog you can turn off scope filtering choice control. This means you can choose Visual Studio or Visual Assist alike style. Using second variant also saves some space in screen area.
2. Added Freeze/Thaw calls to toolbar's choice controls. This massively increases speed of switching between editor files!! Especially noticeable when user switches between large files.
3. Added cbEVT_UPDATE_VIEW_LAYOUT event. This needed to update toolbar size after changing its style in plugin options. Further can be used if we will decide to implement customizable toolbars or when forced layout update is needed.
4. Fixed bug when editor cursor is inside namespace, and it wasn't shown in toolbar.
[attachment deleted by admin]
I've made similar patch, but I haven't found the time to show it to the public :)
One question (I've not looked at the implementation):
Do you sort the Visual Assist style combo? If not please do it, because it is very helpful :)
Quote from: oBFusCATed on March 18, 2010, 02:17:24 PM
Do you sort the Visual Assist style combo? If not please do it, because it is very helpful :)
But make it configurable :D. Because often methods are sorted/grouped by functionality which would get lost if always sorted alphabetically.
Quote from: sbezgodov on March 18, 2010, 01:37:22 PM
1. Now in the plugin options dialog you can turn off scope filtering choice control. This means you can choose Visual Studio or Visual Assist alike style. Using second variant also saves some space in screen area.
I wonder how you would quickly limit the view by namespace using only one combobox. Assume you have a file that works a lot with namespaces and would like to see just the methods of a certain namespace. That's why the initial implementation was splitted into two controls IIRC.
Nice work, I will download the patch and test it, thanks!!!
Edit
I'm thinking about parsing: using namespace statement like:
ParserThread::ParseBufferForNamespaces
I personally think: we can hold these information when we doing the batch parsing, so, these information can be directly retrieved from the Tokentree.
Any body can understand my idea??, sorry if I'm not explain well.
Quote from: MortenMacFly on March 18, 2010, 02:32:50 PM
Quote from: oBFusCATed on March 18, 2010, 02:17:24 PM
Do you sort the Visual Assist style combo? If not please do it, because it is very helpful :)
But make it configurable :D. Because often methods are sorted/grouped by functionality which would get lost if always sorted alphabetically.
Yes, combos are sorted alphabetically case insensitive.
Do you mean to add a toolbar menu button, where you can choose how to display items in comboboxes?
Quote from: ollydbg on March 18, 2010, 03:13:42 PM
I'm thinking about parsing: using namespace statement like:
ParserThread::ParseBufferForNamespaces
I personally think: we can hold these information when we doing the batch parsing, so, these information can be directly retrieved from the Tokentree.
Any body can understand my idea??, sorry if I'm not explain well.
I thought about it, but fear to change anything in Token or TokenTree. :) Is it good idea to store token implementation start/end lines in array or better hold this information in tokens tree? Multiple impl. start/end lines used only for namespaces.
QuoteIs it good idea to store token implementation start/end lines in array or better hold this information in tokens tree? Multiple impl. start/end lines used only for namespaces.
Sorry, I'm not quite understand your idea. Currently, a Token structure is something like:
class Token : public BlockAllocated<Token, 10000>
{
friend class TokensTree;
public:
Token();
Token(const wxString& name, unsigned int file, unsigned int line);
~Token();
void AddChild(int child);
void RemoveChild(int child);
wxString GetNamespace() const;
bool InheritsFrom(int idx) const;
wxString DisplayName() const;
wxString GetTokenKindString() const;
wxString GetTokenScopeString() const;
wxString GetFilename() const;
wxString GetImplFilename() const;
inline unsigned long GetTicket() const { return m_Ticket; }
bool MatchesFiles(const TokenFilesSet& files);
bool SerializeIn(wxInputStream* f);
bool SerializeOut(wxOutputStream* f);
int GetSelf() { return m_Self; } // current index in the tree
wxString GetParentName();
Token* GetParentToken();
TokensTree* GetTree() { return m_pTree; }
wxString m_Type; // this is the return value (if any): e.g. const wxString&
wxString m_ActualType; // this is what the parser believes is the actual return value: e.g. wxString
wxString m_Name;
wxString m_Args;
wxString m_StrippedArgs;
wxString m_AncestorsString; // all ancestors comma-separated list
wxString m_TemplateArgument;
unsigned int m_FileIdx;
unsigned int m_Line;
unsigned int m_ImplFileIdx;
unsigned int m_ImplLine; // where the token was met
unsigned int m_ImplLineStart; // if token is impl, opening brace line
unsigned int m_ImplLineEnd; // if token is impl, closing brace line
TokenScope m_Scope;
TokenKind m_TokenKind;
bool m_IsOperator;
bool m_IsLocal; // found in a local file?
bool m_IsTemp; // if true, the tree deletes it in FreeTemporaries()
bool m_IsConst; // the member method is const (yes/no)
int m_ParentIndex;
TokenIdxSet m_Children;
TokenIdxSet m_Ancestors;
TokenIdxSet m_DirectAncestors;
TokenIdxSet m_Descendants;
wxArrayString m_Aliases; // used for namespace aliases
void* m_pUserData; // custom user-data (the classbrowser expects it to be a pointer to a cbProject)
protected:
TokensTree* m_pTree;
int m_Self; // current index in the tree
unsigned long m_Ticket;
static unsigned long GetTokenTicket();
};
So, You means that the same Tokens(used form, especially they used have different imp start line and end line) can be merged to one Token?
Quote from: ollydbg on March 18, 2010, 04:07:08 PM
So, You means that the same Tokens(used form, especially they used have different imp start line and end line) can be merged to one Token?
Yes, i mean merging exactly to one token. Or make special container in tokentree for additional namespaces information.
Great, works well.
Thanks!
----------------------
Oh, I found a bug: can not find the global functions.
#include <iostream>
using namespace std;
class A
{
public:
void func1() {}
void func2() {}
void func3() {}
};
class B
{
public:
void func1() {}
void func2() {}
void func3() {}
};
class C
{
public:
void func1() {}
void func2() {}
void func3() {}
};
// can not jump to here
void func1() {}
void func2() {}
void func3() {}
int main()
{
cout << "Hello world!" << endl;
return 0;
}
I change xrc's size, like:
<?xml version="1.0" ?>
<resource>
<object class="wxToolBarAddOn" name="codecompletion_toolbar">
<object class="wxChoice" name="chcCodeCompletionScope">
<content/>
<size>220,-1</size>
</object>
<object class="wxChoice" name="chcCodeCompletionFunction">
<content/>
<size>690,-1</size>
</object>
</object>
</resource>
[attachment deleted by admin]
Quote from: Loaden on March 19, 2010, 06:10:02 AM
Oh, I found a bug: can not find the global functions.
Seems that this bug related to parser, because these functions are not displayed in symbols browser too. I use svn6178 revision.
Any suggestions how to make toolbar more configurable, please. Which sort orders do we need? Is manual resizing needed? Is item coloring for different token types needed?
Quote from: sbezgodov on March 19, 2010, 11:16:30 AM
Quote from: Loaden on March 19, 2010, 06:10:02 AM
Oh, I found a bug: can not find the global functions.
Seems that this bug related to parser, because these functions are not displayed in symbols browser too. I use svn6178 revision.
Is not the case, in here, this tip is correct!
[attachment deleted by admin]
If I put the top of the global functions, then all functions are normal!
#include <iostream>
using namespace std;
// can not jump to here
void func1() {}
void func2() {}
void func3() {}
class A
{
public:
void func1() {}
void func2() {}
void func3() {}
};
class B
{
public:
void func1() {}
void func2() {}
void func3() {}
};
class C
{
public:
void func1() {}
void func2() {}
void func3() {}
};
int main()
{
cout << "Hello world!" << endl;
return 0;
}
And if change to:
class A
{
public:
void func1() {}
void func2() {}
void func3() {}
};
// can not jump to here
void func1() {}
void func2() {}
void func3() {}
Now, it's unwork.
WOW! i see, this is indeed parser problem!
If change global function's name to :
// can not jump to here
void gfunc1() {}
void gfunc2() {}
void gfunc3() {}
then, that's work well now.
Following patch formally fixes this bug, Loaden.
Index: token.cpp
===================================================================
--- token.cpp (revision 6178)
+++ token.cpp (working copy)
@@ -521,9 +521,7 @@
if (!curToken)
continue;
- if ( ( (parent < 0)
- || (curToken->m_ParentIndex == parent) )
- && (curToken->m_TokenKind & kindMask) )
+ if ((curToken->m_ParentIndex == parent) && (curToken->m_TokenKind & kindMask))
{
return result;
}
But it makes another questions. Can this patch raise another bugs? :) And why we should return first found token if searched token parent is -1 (Global namespace) ?
@sbezgodov (http://forums.next.codeblocks.org/index.php?action=profile;u=9606)
I have blame the "token.cpp", and it seems these code snippet exists from rev 1711 by rickg22 in 2006-1-11. Maybe, rickg22 can answer your question. But now, he is not so active in this forum. :(
I have read these code, and can't find any reason we don't apply your patch on token.cpp. :D
Any comments from morten or jens or rickg22?
Quote from: ollydbg on March 25, 2010, 06:45:25 AM
I have read these code, and can't find any reason we don't apply your patch on token.cpp. :D
Any comments from morten or jens or rickg22?
I can't either, but it's on freeze atm..
While I am not in the developing team, I think you could let this one slip...
After all, it is correcting an obvious omission from the UI (the permanently disabled listbox), and in that sense, it is a bug fix...
Quote from: ptDev on March 25, 2010, 11:27:13 AM
While I am not in the developing team, I think you could let this one slip...
After all, it is correcting an obvious omission from the UI (the permanently disabled listbox), and in that sense, it is a bug fix...
But it needs much more testing than a 3-liner bug-fix test, because it does change features of the IDE, even if it would be nice to have this working.
I don't think there should be an exception for this.
Hi, I make a little modify, to support global namespace "::".
And it's can be Disable / Enable switch.
Based SVN6204.
[attachment deleted by admin]
Hi, sbezgodov, this patch not work in linux.
Can you check it?