Developer forums (C::B DEVELOPMENT STRICTLY!) > CodeCompletion redesign
CC plugin interface redesign
Alpha:
--- Quote from: oBFusCATed on July 21, 2013, 08:02:16 pm ---Could you commit the parser fixes to the master branch/svn?
--- End quote ---
Okay.
Unrelated changes will remain isolated in the future.
ollydbg:
--- Quote from: golgepapaz on July 08, 2013, 03:55:47 am ---Also every method that is using active editor need boilerplate code something like this;
--- Code: --- cbEditor* editor = Manager::Get()->GetEditorManager()->GetBuiltinActiveEditor();
if (!editor)
return;
if (IsProviderFor(editor))
{
//Do stuff probably involving further indirection to cbStyledTextCtrl.
}
--- End code ---
Pass a viable and healthy editor and save the plugin developer from some suffering. :)
--- End quote ---
Currently, CC just register normal CodeblocksEvent (like project loaded, editor opened) and wxScintilla Events(SCI editor change, SCI editor update...), adding a layer of CCManager is a good idea, thus:
The old way is:
--- Code: --- +-----------------------+ +-----------+
| +--------------->| CC1 |
| + +-----------+
| CodeBlocks Core | +-----------+
| +--------------->| CC2 |
| Scintilla Core | +-----------+
| | +-----------+
| +--------------->| CC3 |
+-----------------------+ +-----------+
--- End code ---
Becomes
--- Code: --- +-----------------------+ +---------+ +-----------+
| +------->| +---->| CC1 |
| + | | +-----------+
| CodeBlocks Core | |CCManager| +-----------+
| +------->| +---->| CC2 |
| Scintilla Core | | | +-----------+
| | | | +-----------+
| +------->| +---->| CC3 |
+-----------------------+ +---------+ +-----------+
--- End code ---
There, CCManager can send valid build-in editor messages.
Mostly, the Parser/Parserthread/Tokenizer class should only have non-GUI things, but if you look at currently trunk code, you will see some GUI stuffs, like:
--- Code: ---BrowserOptions m_BrowserOptions;
--- End code ---
BTW: the logic of the NativeParser and Parser is quite complex, and I can't understand all. (one step is what I wrote here: The parsing flow explanation by a simple example, but far from complete)
ToApolytoXaos:
I was always curious about how Code::Block autocompletion mechanism really works and it seems this thread is the most appropriate. I have tried to read the codecompletion code and could not find where exactly caching is happening.
Is is it in the form of on an object saved in memory, in a Squirrel table, or a flat file which gets deleted upon exiting project? I have seen Pelles C using SQLite and loads remarkably fast during typing; i was really impressed by it.
Also, what is necessary to be done in order to show class / function description along with keyword auto-completion, like what other IDEs are offering?
Another thing that comes to mind. How often does it reparse a project or a file? Is it an application that runs as a background service or is the actual CC plugin that is doing so? Why not let Squirrel do so at the background and save it in a file accordingly and keep it loaded as bytecode in its VM?
ollydbg:
--- Quote from: ToApolytoXaos on July 29, 2013, 03:17:31 pm ---I was always curious about how Code::Block autocompletion mechanism really works and it seems this thread is the most appropriate. I have tried to read the codecompletion code and could not find where exactly caching is happening.
Is is it in the form of on an object saved in memory, in a Squirrel table, or a flat file which gets deleted upon exiting project? I have seen Pelles C using SQLite and loads remarkably fast during typing; i was really impressed by it.
--- End quote ---
TokenTree object in memory, deleted on project closing. No cache on harddisk is used.
--- Quote ---Also, what is necessary to be done in order to show class / function description along with keyword auto-completion, like what other IDEs are offering?
--- End quote ---
Mouse hover on the symbol, then there will be a tip window showing those info.
--- Quote ---Another thing that comes to mind. How often does it reparse a project or a file? Is it an application that runs as a background service or is the actual CC plugin that is doing so? Why not let Squirrel do so at the background and save it in a file accordingly and keep it loaded as bytecode in its VM?
--- End quote ---
reparse triggered depend on user setting, e.g. user is editing on the source file/after saving the source code. Currently there is a thread pool in the CC, so parsing is done in worker thread.
I'm not sure why CC is related to Squirrel?
oBFusCATed:
--- Quote from: ToApolytoXaos on July 29, 2013, 03:17:31 pm ---Why not let Squirrel do so at the background and save it in a file accordingly and keep it loaded as bytecode in its VM?
--- End quote ---
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.
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.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version