CC plugin interface redesign

[ToApolytoXaos]

Wat? CC is done entirely in C++ because it is a part of the application that is performance critical. Why do you think it needs to be written in Squirrel?
There is no database, everything is stored in objects in memory. Nothing is cached on disk.

OK, it's nice to know.

p.s. Please stay on topic. This one is related only to the API interface of a CC plugin.
       If you want to know something about CC or want to improve the parser only then start another one.
       Feature requests for CC not related to this API interface should go in another topic, too.

It was just a question, that's all. I did not suggest anything and there's no need to get irritated for such thing.

[Alpha]

Apologies for the recent silence; my coding is progressing slowly (hopefully I shall have some more to show soon).

After I finish hooking the autocomp box into CCManager, I want to extract the fallback procedures from the main CC plugin to create a dedicated fallback CC (core plugin).  Comments?

[ollydbg]

One patch to add files to codeblocks.cbp(not tested, by I just synchronized with unix.cbp)

Code

 src/CodeBlocks.cbp | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/src/CodeBlocks.cbp b/src/CodeBlocks.cbp
index 9967ad3..8e25d83 100644
--- a/src/CodeBlocks.cbp
+++ b/src/CodeBlocks.cbp
@@ -817,6 +817,9 @@
 		<Unit filename="include/cbworkspace.h">
 			<Option target="sdk" />
 		</Unit>
+		<Unit filename="include/ccmanager.h">
+			<Option target="sdk" />
+		</Unit>
 		<Unit filename="include/compileoptionsbase.h">
 			<Option target="sdk" />
 		</Unit>
@@ -2502,6 +2505,9 @@
 		<Unit filename="sdk/cbworkspace.cpp">
 			<Option target="sdk" />
 		</Unit>
+		<Unit filename="sdk/ccmanager.cpp">
+			<Option target="sdk" />
+		</Unit>
 		<Unit filename="sdk/compileoptionsbase.cpp">
 			<Option target="sdk" />
 		</Unit>

Question:
What does the int id member of the CCToken used for? It is an index to a specific TokenTree (TokenTree only exists in C++ Parser, and in a specified Parser instance)

Some changes are not related to CC interface changes, so I suggest you can use the "git rebase --interactive, then rebase on git-svn branch", or other similar tools like "git cherry pick tool" to extract those patches, and apply on trunk.

I still need more time to read/understand all your changes.

[Alpha]

[...] hopefully I shall have some more to show soon.

Well... maybe soon.  Health issues have prevented my coding.  I do have enough completed now that my next commit should be possible this sometime weekend.

What does the int id member of the CCToken used for?

It is non-functional currently, however, I put it there so that a CC callback or documentation popup can pass a plugin specific piece of information back to the plugin.  My next commit should clarify that.

[Alpha]

In reading through what I have done so far, it appears I may have created somewhat redundant functions.

Code

virtual std::vector<CCToken> GetAutocompList(int& tknStart, int& tknEnd, cbEditor* ed) = 0;
virtual std::vector<CCToken> GetTokenAt(int pos, cbEditor* ed) = 0;

Would it be preferred for me to combine them into a single function?

Code

#define CC_PREFIX true
#define CC_FULL_TOKEN false
virtual std::vector<CCToken> GetTokenAt(int pos, cbEditor* ed, bool isPrefix = CC_FULL_TOKEN) = 0;

(...taking a break from code makes it all look so foreign .)

[oBFusCATed]

Probably you've lost direction in your changes, because I saw you've added another edit->complete code item (shift-space hotkey). Why? What is it purpose?

The two defines are extremely ugly. Try to no use them and use an enum instead or even enum in a struct (to simulate the strong enum c++11 feature).

What is supposed to do  GetTokenAt and what is supposed to do GetAutocompList?
If they do different things it doesn't matter that they have similar signatures/return types - you should keep them separate.

[Alpha]

[...] I saw you've added another edit->complete code item (shift-space hotkey). Why? What is it purpose?

The entry used to be supplied by the main CC plugin.  I moved it to the application, so that CCManager can make the same shortcut work for any/all CC plugins.

GetTokenAt() currently only supplies information for showing tooltips, however, I intended it to be something that another plugin, ex. debugger, could call for more accurate results when doing some other operation.  GetAutocompList() supplies tokens for the code completion popup by looking at the prefix.

Probably you've lost direction in your changes [...]

Probably.

[oBFusCATed]

From you explanation I conclude that:
1. GetTokenAt could return multiple tokens depicting full tokens (type, name, namespace, parameteres, etc), for example multiple functions.
2. GetAutocompList returns also multiple tokens, but they are different from the ones returned in GetTokenAt.
    They are just member function names, type info, parameters.
3. The debugger needs only the full name or better name it the expression. No need for function parameters, type, namespace, etc.
    The debugger needs the name of a member expanded to the full expression used to access it.
    At the moment if you hover over a member you'll get just the member and if you try to evaluate it, you'll get "variable not found in scope", because you tried to evaluate variable "member1" instead of "a.b->c->member1". The debugger needs a way to expand a particular string word to the full expression at the cursor. So we need a different method here again.

Also I don't think you need to worry too much if you add too many pure methods.
If the plugin developer thinks it is best to handle them the same, he can do so no problem (he can add a common method and convert parameters).
Providing clear and separate names is better for source readability. An API where you have a few functions that do lots of stuff is most of the times worse than an API with many functions doing simple things each...

Also don't worry, just iterate on the API until it feels good to you...

[Alpha]

If I need to modify the return of, say:

Code

virtual std::vector<CCToken> GetAutocompList(int& tknStart, int& tknEnd, cbEditor* ed) = 0;

is it the preferred style to use:

Code

virtual void GetAutocompList(std::vector<CCToken>& tokens, int& tknStart, int& tknEnd, cbEditor* ed) = 0;

to avoid a (potentially) expensive copy on the vector?

[oBFusCATed]

It depends...

c++11: The first one is almost always better.
c++98: It depends on some things:
   - Is the copy really expensive (many elements in the vector)?
   - Will it be called many times and so the copy will show in the profiler?

If the answers to both questions is no, then I'll use the first style otherwise the second.

[jarod42]

In this example, it seem that there are several "returned" values (int&).
So, I think it is better to have something similar for all these items (so the return void solution).

Order may also be important, I prefer generally ([in], [in/out], [out]) order.

[Alpha]

c++11: The first one is almost always better.

I do not believe it is yet time to restrict Code::Blocks to the new standard, so:

   - Is the copy really expensive (many elements in the vector)?
   - Will it be called many times and so the copy will show in the profiler?

It occurs each time the auto-complete box is populated.  I do not have exact numbers, however sometimes the number of tokens is large; as this can be a user requested operation, I think it would be best to minimize any potential sense of lag.  (Unfortunately, I currently do not have access to average/slower hardware, so I cannot tell if it is yet noticeable.  Only having access to fast computers is a problem I like having.)

I think it might be best to go with the second style.  Which brings up:

Order may also be important, I prefer generally ([in], [in/out], [out]) order.

I normally try to order parameters such that the ones that are most important/vital to the main purpose of function come first, and less useful (possibly omit-able) parameters are last.  Does Code::Blocks already have a design style in reference to this?

To anyone who might be currently trying (or considering trying) my branch, it currently should have all the functionality of the trunk except for automatic adding of parentheses after functions, and documentation popups.  Probably the only visible change is that tooltips should be a bit more stable.

[oBFusCATed]

It occurs each time the auto-complete box is populated.  I do not have exact numbers, however sometimes the number of tokens is large; as this can be a user requested operation, I think it would be best to minimize any potential sense of lag.  (Unfortunately, I currently do not have access to average/slower hardware, so I cannot tell if it is yet noticeable.  Only having access to fast computers is a problem I like having.)

1. There is a limit to the number of entries this should return in the UI.
2. You can always downclock your CPU and you can disable cores to test. Turn you CPU in a single core 1.5ghz and test again

Order may also be important, I prefer generally ([in], [in/out], [out]) order.

I'd follow this one, because it is clear what is in and out parameter.

[Alpha]

1. There is a limit to the number of entries this should return in the UI.

Yes, but the default limit is currently so high, I do not believe I have ever hit it.

2. You can always downclock your CPU and you can disable cores to test. Turn you CPU in a single core 1.5ghz and test again

Downclocked, disabled turbo, and disabled hyperthreading.  For some reason, the BIOS failed to disable extra cores.  When asking for a long auto-complete list (for example, code complete after the letter 's'), I did notice an additional lag.

Order may also be important, I prefer generally ([in], [in/out], [out]) order.

I'd follow this one, because it is clear what is in and out parameter.

Okay.  Will do.

[oBFusCATed]

I did notice an additional lag.

Have you measured how long more does it take?