Author Topic: CC plugin interface redesign  (Read 155039 times)

Offline dmoore

  • Developer
  • Lives here!
  • *****
  • Posts: 1576
Re: CC plugin interface redesign
« Reply #105 on: November 07, 2013, 04:40:58 pm »
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 will incorporate that. thx.

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

Yeah, I noticed the empty calltip would pop up occasionally. Maybe that's what is coming from the jedi completion lib because I don't think my code does this. I will try stripping it and see if that fixes the issue.

Offline frithjofh

  • Regular
  • ***
  • Posts: 376
Re: CC plugin interface redesign
« Reply #106 on: November 09, 2013, 03:17:47 pm »
hi everybody,

I was following this thread for some time now. and I keep stumbling on the same question:

shouldn't all this code completion stuff be separated in two things?

if I understand right one big block of this is the actual analysis of the code and parsing it into some kind of searchable structure, lets call it the TREE. this is dependent on the language. it is focused on analysis and is somewhat abstract. by all means a very basic and low level work and part of c::b.

the other part is putting this information to use for the developer. here in this special case for code completion. this is rather like using only a tiny part of the underlying information and potential of the TREE.

this separation is illustrated too by the  way there exists the symbols tab inside the manager panel. this has functionally nothing to do with the code completion pop up really...

and there are other plugins that could leverage the information of the TREE: the code refactoring plugin to edit individual symbols, the search plugins, which could use it to search for entities by type (variables, members, functions, classes) instead of only by name, the statistic plugin... and I bet a bunch more of functionalities inside of c::b, plugin or not.

so, should this not better be separated? the TREE as a base part of c::b, parsing code for everybody free to use the information, maybe not even as a plugin at all, and then the actual code completion as a plugin?

regards and sorry in advance if this post is only boring/annoying the devs...

frithjofh
« Last Edit: November 09, 2013, 03:21:14 pm by frithjofh »
architect with some spare time  -  c::b compiled from last svn  -   openSuSE leap x86_64  -  AMD FX-4100

Offline Alpha

  • Developer
  • Lives here!
  • *****
  • Posts: 1513
Re: CC plugin interface redesign
« Reply #107 on: November 10, 2013, 04:58:22 pm »
shouldn't all this code completion stuff be separated in two things?
On the longest term, that would have the greatest flexibility.  However I currently do not have the skill to create a language independent AST.  Maybe that is something for the next iteration of the CC interface... it is quite a bit more complicated than I can easily visualize.

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: CC plugin interface redesign
« Reply #108 on: November 10, 2013, 08:44:06 pm »
Interested people could look at kdevelop's source code, I think they have something like this already implemented.
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline darmar

  • Multiple posting newcomer
  • *
  • Posts: 68
Re: CC plugin interface redesign
« Reply #109 on: January 24, 2014, 06:57:18 pm »
Hi,

I am playing with this cc_interface branch currently, and found a feature or a bug, but I am not sure.

Code
 int main ()
{
  int i = my_function(undefined_variable);
}

If I keep the mouse over "undefined_variable", a call-tip for "my_function" will be showed. I think,  the function CodeCompletion::GetTokenAt is called at first, but because this function returns an empty vector, the function CodeCompletion::GetCallTips is called.

Is it a feature? If yes, I should find a workaround for FortranProject plugin.


Offline Alpha

  • Developer
  • Lives here!
  • *****
  • Posts: 1513
Re: CC plugin interface redesign
« Reply #110 on: January 25, 2014, 01:25:44 am »
Is it a feature? If yes, I should find a workaround for FortranProject plugin.
The intent was for it to be a feature.  Would it work better for you if CCManager only used the calltip fallback if it is whitespace under the mouse?  Or do you want to be able to completely disable it?

Offline darmar

  • Multiple posting newcomer
  • *
  • Posts: 68
Re: CC plugin interface redesign
« Reply #111 on: January 25, 2014, 07:03:14 am »
May be, it would be better to define GetTokenAt with default parameter something like:

std::vector<CCToken> GetTokenAt(int pos, cbEditor* ed, bool fallbackCalltip = true);



Offline Alpha

  • Developer
  • Lives here!
  • *****
  • Posts: 1513
Re: CC plugin interface redesign
« Reply #112 on: January 26, 2014, 01:54:17 am »
Control parameter committed.

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: CC plugin interface redesign
« Reply #113 on: February 07, 2014, 01:18:30 am »
Alpha: Can you start preparation of the branch for a push in svn?
To do so:
0. add and push a tag for the current pointer of your branch. This will help if someone has commits on top of your branch.
1. pull the master from my repo
2. checkout your branch
3. git rebase master (or the remote/blabla/master)
4. fix all conflicts
5. git push -f yourbranch

Probably it would be good to try to setup your repo for svn dcommit, so you can push the changes yourself, because if I push them, then I'll be the author in the history.
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline Alpha

  • Developer
  • Lives here!
  • *****
  • Posts: 1513
Re: CC plugin interface redesign
« Reply #114 on: February 09, 2014, 06:03:20 am »
Alpha: Can you start preparation of the branch for a push in svn? [...]
Okay (might have a few delays; sorry, life can get busy :-\ ).
Do you have some details for svn dcommit?  (So far, I have just been using plain git with my branch.)

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: CC plugin interface redesign
« Reply #115 on: February 09, 2014, 09:47:54 am »
Read this topic: http://forums.codeblocks.org/index.php/topic,16096.45.html somewhere in it you can find how to add your svn info to the repo. I'm not sure you need to rewrite your history in order to make git svn dcommit work.
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline Alpha

  • Developer
  • Lives here!
  • *****
  • Posts: 1513
Re: CC plugin interface redesign
« Reply #116 on: February 13, 2014, 05:54:00 pm »
0. add and push a tag for the current pointer of your branch. This will help if someone has commits on top of your branch.
1. pull the master from my repo
2. checkout your branch
3. git rebase master (or the remote/blabla/master)
4. fix all conflicts
I have done up to this step, however, now my local branch has a few pieces of code that are different than before (and I am fairly certain I had correctly resolved all conflicts).  Is it okay to commit a fix/revert of these (incorrect) changes on top of the rebase?

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: CC plugin interface redesign
« Reply #117 on: February 14, 2014, 12:22:52 am »
Yes, it is. If you don't this dummy commit you can squash it back again in the commit that has introduced the changes you don't like. This way your history will be clean. :)
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline Alpha

  • Developer
  • Lives here!
  • *****
  • Posts: 1513
Re: CC plugin interface redesign
« Reply #118 on: February 14, 2014, 01:39:16 am »
Done resolving conflicts, and committed to my git branch.

The problem of setting up git svn, though, I am unsure how to solve.  Trying to use a git svn command resulted in:
Code
Migrating from a git-svn v1 layout...
Data from a previous version of git-svn exists, but
.git/svn
(required for this version (1.8.3.2) of git-svn) does not exist.
Done migrating from a git-svn v1 layout
and then indefinite hang.  From my understanding of reading http://forums.codeblocks.org/index.php/topic,16096.45.html (and searching the web), the expected process of using git svn is starting from an svn repository.  Because I started originally from standard git, I have not been able to figure out how to hook into the svn repository.  Suggestions?

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5916
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: CC plugin interface redesign
« Reply #119 on: February 14, 2014, 04:48:44 am »
Done resolving conflicts, and committed to my git branch.

The problem of setting up git svn, though, I am unsure how to solve.  Trying to use a git svn command resulted in:
Code
Migrating from a git-svn v1 layout...
Data from a previous version of git-svn exists, but
.git/svn
(required for this version (1.8.3.2) of git-svn) does not exist.
Done migrating from a git-svn v1 layout
and then indefinite hang.  From my understanding of reading http://forums.codeblocks.org/index.php/topic,16096.45.html (and searching the web), the expected process of using git svn is starting from an svn repository.  Because I started originally from standard git, I have not been able to figure out how to hook into the svn repository.  Suggestions?
Hi, alpha, I just clone your git https://github.com/alpha0010/codeblocks_sf/tree/cc_interface
I see that all the change is based on the latest C::B svn/git head, great!

I guess that the git you use does not contains any svn information to allow you to do git svn dcommit, so this is what I suggest:
1, simply clone a new git repo(we call it local-git-new-repo) from official C::B SVN, note you should use C::B SVN address you have write access. Since a git svn clone of the whole C::B svn history takes long time, you can have either two ways
a, you can clone a C::B svn starting from a specified svn revision, for example, from rev 9640, so in your local git, you can only have a history about 10 commits. That should be a very fast clone, because git svn command only fetch nearly 10 commits. The important thing is with this git clone, you can use git svn dcommit to commit to C::B svn repo.
b, you can copy a raw git achieve from other one, e.g. jens supply one, see this page Re: Read-only Git, SVN Repo for Code::Blocks, when downloaded, you need to some further steps to change the svn information, so that you have a git repo which can commit back to svn, also you have a full svn history.

2, you can use the git format-patch command to generate a serial patches from your https://github.com/alpha0010/codeblocks_sf/tree/cc_interface (we call it local-git-old-repo).

3, you can use git am command to apply the patches to local-git-new-repo.

4, use local-git-new-repo to commit(git svn dcommit) back the changes to C::B official svn repo.

Now, you can see all the changes in local-git-old-repo is now in local-git-new-repo, and further in C::B svn repo.

BTW: you can also arrange your changes by "git rebase -i" (interactive git rebase), you can divide commits, merge commits, edit commit log messages, drop commits, all what you know.  :)


EDIT: look at your previous message, I guess some git svn tool is missing? I don't know, because under Windows, I have no problems using msysgit + tortoisegit, many operations can be mouse click on tortoiisegit, but some special command like "git rebase -i" should be run in msysgit's bash shell to get more functionality due to tortoisegit limitation.



« Last Edit: February 14, 2014, 04:52:18 am by ollydbg »
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.