CC plugin interface redesign

[Folco]

Oh my god, a documentation calltip like what I always wanted to have ! \o/ Good job

[dmoore]

Oh my god, a documentation calltip like what I always wanted to have ! \o/ Good job

Yes. Big props to the good work by p2rkw and alpha!

[Alpha]

Code

            CodeBlocksEvent evt(cbEVT_COMPLETE_CODE);
            Manager::Get()->GetPluginManager()->NotifyPlugins(evt);

So this works, but it is a little confusing for me to say "NotifyPlugins" when I actually mean "Notify CC Manager (to notify me)"

I would recommend:

Code

        CodeBlocksEvent evt(cbEVT_COMPLETE_CODE);
        Manager::Get()->ProcessEvent(evt);

So it turns out that the old default STC behavior of appending a ? and a number e.g. "print?1" also works.

If that works, then the revision you are compiling against is out of date.  Also, it is unnecessary now; instead assign the number to the (new) category member of CCToken.

btw, is it expected that a plugin will need to register its own images:

Currently you will have to.  I am still thinking about if there is a good way to allow plugins to register (or even share) images through CCManager.

1. what do I put in hlStart, hlEnd and argsPos?

hlStart and hlEnd are: if you appended all of the strings that GetCallTips() returns, what would be the starting and ending indicies of the desired highlighted range.

2. The active calltip is getting automatically hidden after less than second. Any idea why this might be happening?

You must put a location in argsPos which represents the starting position (in the stc) of the arguments, for example the argsPos for when the cursor is anywhere inside GetCallTips() - but not inside GetStyleAt() - would be:

Code

    const wxStringVec& tips = ccPlugin->GetCallTips(pos, stc->GetStyleAt(pos), ed, hlStart, hlEnd, argsPos);
                                                   ^

It is being cancelled immediately because CCManager uses the argsPos variable to determine what calltips are the same, or in the case of wxSCI_INVALID_POSITION (-1) , invalid.

If you want to test the code is in svn here: http://developer.berlios.de/svn/?group_id=7745

PythonCodeComletion-cc contains the code that's compatible with your branch. I've hard-coded the links in the unix project file. I haven't tested on windows at all, so the windows project file may compile without tweaks, but no guarantee.

My apologies, but it will not compile just yet, it seems I have already broken API with you.  I will try to post some patches for yours, when I have time.

Oh my god, a documentation calltip like what I always wanted to have ! \o/ Good job

Yes. Big props to the good work by p2rkw and alpha!

My branch has mostly just migrated the code p2rkw wrote.  (Display logic in my branch is slightly different, and *hopefully* acts a little more stable.)

[dmoore]

So it turns out that the old default STC behavior of appending a ? and a number e.g. "print?1" also works.

If that works, then the revision you are compiling against is out of date.  Also, it is unnecessary now; instead assign the number to the (new) category member of CCToken.

But is there any good reason not to support the stc method? The stc control wants the symbol?category syntax so why not just support that?

btw, is it expected that a plugin will need to register its own images:

Currently you will have to.  I am still thinking about if there is a good way to allow plugins to register (or even share) images through CCManager.

It is probably fine as is, but it won't be obvious for someone using the API for the first time, so include some docs somewhere.

1. what do I put in hlStart, hlEnd and argsPos?

hlStart and hlEnd are: if you appended all of the strings that GetCallTips() returns, what would be the starting and ending indicies of the desired highlighted range.

Can you give an example of what you mean? The array represents the multiple matching calls or the args?

2. The active calltip is getting automatically hidden after less than second. Any idea why this might be happening?

You must put a location in argsPos which represents the starting position (in the stc) of the arguments, for example the argsPos for when the cursor is anywhere inside GetCallTips() - but not inside GetStyleAt() - would be:

Code

    const wxStringVec& tips = ccPlugin->GetCallTips(pos, stc->GetStyleAt(pos), ed, hlStart, hlEnd, argsPos);
                                                   ^

So argsPos is always the stc position of the opening brace?

What if the user presses "," but the cursor is not in a function call (e.g. python tuple or list)? Will GetCallTip be called and should the plugin return nothing?

If you want to test the code is in svn here: http://developer.berlios.de/svn/?group_id=7745

PythonCodeComletion-cc contains the code that's compatible with your branch. I've hard-coded the links in the unix project file. I haven't tested on windows at all, so the windows project file may compile without tweaks, but no guarantee.

My apologies, but it will not compile just yet, it seems I have already broken API with you.  I will try to post some patches for yours, when I have time.

No need to - use the time to create doc strings  . I should be able to keep up with your changes.

[dmoore]

There was only a small change needed to compile against your changes, but now there are other problems...

Code

PythonCodeCompletion::CCProviderStatus PythonCodeCompletion::GetProviderStatusFor(cbEditor* ed)
{
    Manager::Get()->GetLogManager()->Log(_("PYCC: Provider status check"));
    if (ed->GetLanguage() == ed->GetColourSet()->GetHighlightLanguage(wxSCI_LEX_PYTHON))
        return ccpsActive;
    if (ed->GetControl()->GetLexer()==wxSCI_LEX_PYTHON)
        return ccpsActive;
    Manager::Get()->GetLogManager()->Log(_("PYCC: Provider status check INACTIVE"));
    return ccpsInactive;
}

Neither of those checks return true because it seems that the call occurs before the lexer is set. Also, how will you handle the case where the user changes the highlight language to something else? It looks like your code only checks once for each editor, no? What was wrong with the old mechanism? Surely it wasn't that inefficient to ping a few plugins before each call? (I don't mind you changing as long as it works!)

[dmoore]

alpha: my latest svn rev is now in sync with your branch and now more or less correctly displays call tips with highlighting.

[Alpha]

So it turns out that the old default STC behavior of appending a ? and a number e.g. "print?1" also works.

If that works, then the revision you are compiling against is out of date.  Also, it is unnecessary now; instead assign the number to the (new) category member of CCToken.

But is there any good reason not to support the stc method? The stc control wants the symbol?category syntax so why not just support that?

The stc method is still supported (except it must be '\n'); if you do not set the category member, CCManager will not attempt to append it, so "symbol\ncategory" will work.  I changed both the separator and type separator from defaults because I was becoming frustrated with strange bugs when a returned token contained one of these.  I selected two characters that should never exist in a token: '\n' and '\r'.
Having category as a member, though, will allow CCManager to more easily do things like provide a standard set of icons, and add an offset to the values (planned ideas, no code yet written).

So argsPos is always the stc position of the opening brace?

That is my intention.

What if the user presses "," but the cursor is not in a function call (e.g. python tuple or list)? Will GetCallTip be called and should the plugin return nothing?

Yes, my thoughts were that: rather than having a ccPlugin check every change to an editor to see if it should take an action, filter it so only the 'interesting' changes notify the plugin(s), and then the plugin can decide if it was a false positive.

No need to - use the time to create doc strings  . I should be able to keep up with your changes.

I was writing just for myself for a while... I guess I need to start on some more documentation though.

Neither of those checks return true because it seems that the call occurs before the lexer is set. Also, how will you handle the case where the user changes the highlight language to something else? It looks like your code only checks once for each editor, no? What was wrong with the old mechanism? Surely it wasn't that inefficient to ping a few plugins before each call? (I don't mind you changing as long as it works!)

Strange... it seems to work with the main CC plugin.  I will look into it.
It will check editors multiple times; it only skips the check if it is on the same editor that was last called.  I did this because GetProviderStatusFor() could potentially do multiple string comparisons, and I did not want to worry about avoiding calling this multiple times in quick succession.  (Also, the structure is there so I can add some more planned logic into each time a check is called on a new editor.)

[dmoore]

If you want to test the provider stuff in my plugin you need to remove the first line of the provider method which immediately returns "active".

Btw, most of this is working really well! When you are happy with this part of the interface and it is stable, I suggest you merge it back to trunk before you move on to symbol browsing.

[dmoore]

Re docs, the main thing is to put doc strings in cbplugin.h for the virtual methods that explain the things you have explained to me in this thread. I should be able to help with this.

[Alpha]

If you want to test the provider stuff in my plugin you need to remove the first line of the provider method which immediately returns "active".

Should work now.
Some comments on your plugin; I did add default implementations for DoAutocomplete(), so these can be removed (until such a time as you decide to override them).  Avoid calls to control->GetCurrentPos() on any functions where CCManager passes you a position (although the passed position is sometimes the current position, it is not always).  The main CC plugin (@devs: we might need to rename this plugin at some point, to reduce confusion) checks against GetHighlightLanguage() because wxSCI_LEX_CPP lexer is being multipurposed for about seven other languages, but with Python, a simple ID comparison should be fine.

Code

Index: PythonCodeCompletion.cpp
===================================================================
--- PythonCodeCompletion.cpp	(revision 434)
+++ PythonCodeCompletion.cpp	(working copy)
@@ -7,7 +7,6 @@
 #include <cbeditor.h>
 #include <cbstyledtextctrl.h>
 #include <editor_hooks.h>
-#include <editorcolourset.h>
 #include <configmanager.h>
 #include <logmanager.h>
 //
@@ -399,10 +398,7 @@
 
 PythonCodeCompletion::CCProviderStatus PythonCodeCompletion::GetProviderStatusFor(cbEditor* ed)
 {
-    return ccpsActive; // WORKAROUND UNTIL ALPHA FIXES THIS
     Manager::Get()->GetLogManager()->Log(_("PYCC: Provider status check"));
-    if (ed->GetLanguage() == ed->GetColourSet()->GetHighlightLanguage(wxSCI_LEX_PYTHON))
-        return ccpsActive;
     if (ed->GetControl()->GetLexer()==wxSCI_LEX_PYTHON)
         return ccpsActive;
     Manager::Get()->GetLogManager()->Log(_("PYCC: Provider status check INACTIVE"));
@@ -529,18 +525,6 @@
     return doc;
 }
 
-/// callbacks for actually autocompleting/writing the token to the editor
-void PythonCodeCompletion::DoAutocomplete(const CCToken& token, cbEditor* ed)
-{
-    return;
-}
-
-void PythonCodeCompletion::DoAutocomplete(const wxString& token, cbEditor* ed)
-{
-    DoAutocomplete(CCToken(-1, token), ed);
-}
-
-
 void PythonCodeCompletion::RequestCompletion(cbStyledTextCtrl *control, int pos, const wxString &filename)
 {
     int line = control->LineFromPosition(pos);
Index: PythonCodeCompletion.h
===================================================================
--- PythonCodeCompletion.h	(revision 434)
+++ PythonCodeCompletion.h	(working copy)
@@ -121,9 +121,6 @@
         virtual std::vector<CCToken> GetTokenAt(int pos, cbEditor* ed);
         /// dismissPopup is false by default
         virtual wxString OnDocumentationLink(wxHtmlLinkEvent& event, bool& dismissPopup);
-        /// callbacks for actually autocompleting/writing the token to the editor
-        virtual void DoAutocomplete(const CCToken& token, cbEditor* ed);
-        virtual void DoAutocomplete(const wxString& token, cbEditor* ed);
 
     protected:
         /** Any descendent plugin should override this virtual method and
Index: PythonCodeCompletion-unix.cbp
===================================================================
--- PythonCodeCompletion-unix.cbp	(revision 434)
+++ PythonCodeCompletion-unix.cbp	(working copy)
@@ -23,7 +23,7 @@
 				<Option type="3" />
 				<Option compiler="gcc" />
 				<Option parameters="--debug-log --multiple-instance -ni -v -p debug" />
-				<Option host_application="/home/damien/src/codeblocks-cc/src/devel/codeblocks" />
+				<Option host_application="../../codeblocks-cc/src/devel/codeblocks" />
 				<Option run_host_application_in_terminal="1" />
 				<Compiler>
 					<Add option="-ansi" />

[dmoore]

Very nice, thanks. And ooh that abs path   feel like such a smurf.

I still need to test out the html links and then give some thought to how to handle symbol browser. (Note that the current categories "Global functions", "Global typedefs", Global variables", Preprocessor symbols", "Global macros" don't fit that well with python)

[Alpha]

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;

(I think your plugin sometimes returns " " as a calltip; probably it is the plugin's job, not CCManager, to filter that.)

[oBFusCATed]

Alpha: Can I ask you to try to describe your commits in more detail (what and why you're doing in the commit is important), especially commits changing core sdk stuff like cbEditor.

[Alpha]

Okay, will do.  (That specific commit was to prevent editor hooks from calling plugins before the editor was completely initialized.)  Would you like me to try to edit past commit messages?

[oBFusCATed]

Would you like me to try to edit past commit messages?

Yes, please