Developer forums (C::B DEVELOPMENT STRICTLY!) > CodeCompletion redesign

CC plugin interface redesign

<< < (2/28) > >>

oBFusCATed:

--- Quote from: Alpha on July 04, 2013, 06:27:38 pm ---Having a single tab that various plugins can swap the contents with makes sense.  The question is, when to swap?  Each time the active editor changes?  If there are split editors?  No editor open?  Swap on demand (with a combo box)?

--- End quote ---
Have I said something about swapping. :) For me there is no problem to show symbol info from all plugins at once.
You can do some filters and stuff. But I suppose this is a feature that should be done at a later stage.
(btw I don't use symbols browsers, so I don't know the workflows).


--- Quote from: Alpha on July 04, 2013, 06:27:38 pm ---I have not used git before, but I am willing to try.  Do you have a quick overview of normal git workflow?

--- End quote ---
Hm, not that easy. :)
Probably start from here: http://stackoverflow.com/questions/315911/git-for-beginners-the-definitive-practical-guide
For you the steps would be:
1. clone the master
2. create new branch
3. commit, commit, commit
4. push to your github accout,
5 ask for pull in github, so I can upload your changes to the repo.

I'm not really sure about the 4th step, because I've never done multi-people-workflow in github.


--- Quote from: Alpha on July 04, 2013, 06:27:38 pm ---What I want to do is first delete most of the CC plugin, except for the parser.  Then add on/rewrite each feature as the changes to the SDK are finished.

--- End quote ---
If I were you I won't delete any code, but start extracting parts and making sure everything else still works.
And remember to leave as many as needed // FIXME comments. :)

oBFusCATed:
Another task I have in mind is one very simple keyword-like cc plugin that works for unsupported files (php, python, lua, etc).
I have to edit such files from time to time and I feel the need for such CC. :)

Folco:
You think to a cc based on the xml files of Scintilla lexers ?

Josh @ Dreamland:
Hi there; I hope no one minds an "outsider" weighing in.  :)

From where I'm standing, it looks like you're asking quite a lot of a generic CC plugin. A parser is a very easily isolated data operation, while the symbol explorer sounds pretty UI-heavy, and a lot of the refactoring and search-related functionality is universal regardless of who is doing the parsing. I'm of the opinion that there should be two plugin types, here; a parsing plugin (based on Clang, on GCC-XML, or hand-rolled, or what have you), and then a code-completion plugin on top of that to handle the refactoring and symbol browsing (assuming that should not likewise be broken up).

Clang's API, as well as a thin layer over GCC-XML, would both be able to perform tasks such as enumerating contents of a scope, giving occurrences of an identifier which refer to the same object, enumerating parameters to a given function, resolving an overload, and evaluating/coercing expressions. These are fundamentals of any compiler, and all the tools that a bigger code-completion plugin would need to do code completion, refactoring, method/class extraction, among other helpful features.

If there was a plugin for code completion, and a separate plugin for code parsing, the same refactoring and code completion plugin could be used with any decently capable parser plugin.


--- Quote ---One thing you've missed is an API for getting the full symbol at one position in a file.
For example if you select a struct member and want to see it in the debugger tooltip, the debugger plugin needs to
expand the string to instance of the object, so the variable could be evaluated correctly by the debugger.
--- End quote ---
This is also needed for refactor:rename. If it's even slightly useful in the debugger plugin, that's all the more reason to include this in either API.

Just my thoughts.
Cheers

oBFusCATed:

--- Quote from: Josh @ Dreamland on July 05, 2013, 06:36:38 pm ---From where I'm standing, it looks like you're asking quite a lot of a generic CC plugin. A parser is a very easily isolated data operation, while the symbol explorer sounds pretty UI-heavy, and a lot of the refactoring and search-related functionality is universal regardless of who is doing the parsing. I'm of the opinion that there should be two plugin types, here; a parsing plugin (based on Clang, on GCC-XML, or hand-rolled, or what have you), and then a code-completion plugin on top of that to handle the refactoring and symbol browsing (assuming that should not likewise be broken up).

......

If there was a plugin for code completion, and a separate plugin for code parsing, the same refactoring and code completion plugin could be used with any decently capable parser plugin.

--- End quote ---
But then what happens if the CC plugin is unloaded and the parser plugin tries to use/access it. The common parts should be in the SDK or in the Main application. It is just simpler to design/implement it this way.
If we have to have plugins for the plugins, then something is wrong. :)

Navigation

[0] Message Index

[#] Next page

[*] Previous page