Developer forums (C::B DEVELOPMENT STRICTLY!) > Plugins development
Semantic highlight
oBFusCATed:
mistar:
Is it possible to make the required changes in the SDK, so multiple plugins can be semantic highlight providers?
I guess if we make a CC plugin based on clang we have to implement the semantic highlight in it in order to prevent calling clang to parse the code twice.
Is the parsing required for CC and semantic parsing the same?
mistar:
--- Quote from: oBFusCATed on May 17, 2012, 10:22:02 am ---mistar:
Is it possible to make the required changes in the SDK, so multiple plugins can be semantic highlight providers?
I guess if we make a CC plugin based on clang we have to implement the semantic highlight in it in order to prevent calling clang to parse the code twice.
Is the parsing required for CC and semantic parsing the same?
--- End quote ---
AFAIK, clang_codeCompleteAt calls clang_reparseTranslationUnit, see the description of clang_defaultEditingTranslationUnitOptions here: http://clang.llvm.org/doxygen/group__CINDEX__TRANSLATION__UNIT.html
oBFusCATed:
I've never looked at the clang's API and I restrain myself from doing so, because I'd be caught in a nasty CC refactoring. :P
mistar:
--- Quote from: MortenMacFly on May 15, 2012, 08:41:54 am ---I think there is a better way: Instead of introducing another event, you could move the portion:
--- Code: --- if (can_updateui)
{
if (ed)
{
SetActiveEditor(ed);
ed->GetControl()->SetFocus();
}
}
--- End code ---
...to after:
--- Code: --- // check for ProjectFile
if (ed && !ed->GetProjectFile())
{
// First checks if we're already being passed a ProjectFile as a parameter
if (data)
Manager::Get()->GetLogManager()->DebugLog(_T("Project data set for ") + data->file.GetFullPath());
else
Manager::Get()->GetProjectManager()->FindProjectForFile(ed->GetFilename(), &data, false, false);
if (data)
ed->SetProjectFile(data,true);
}
--- End code ---
This way, you can use the already existing cbEVT_EDITOR_ACTIVATED event and don't screw anything.
I'll check this in my local copy and look for side-effects (but I cannot think of any for the moment...).
--- End quote ---
Well, this is not what I need... My understanding of cbEVT_EDITOR_ACTIVATED is that it is posted whenever an editor gets focus...
What I really need is an event that is posted when a file is opened in C::B to set up clang data (index, translation unit, ...) for that file
AND containing all necessary data like the project the file belongs to (to read the project's compiler options needed to correctly set up the index).
BTW, it is good practice to name things adequately so that others can understand our code ;) Therefore, if cbEVT_EDITOR_OPEN is reserved for
"is about to be opened" (and there is no extra data set up at the moment), then I believe that there might (or even should) be another event, e.g. cbEVT_EDITOR_LOADED
(this is probably better name) or whatever, signaling that the opening action is completed with all the data set up correctly.
Observe also, that my implementation shouldn't screw anything: it is just a piece of code added to what exists and this code shouldn't interfere with
the existing code.
Last but not least, cbEVT_PROJECT_OPEN event is not semantically "is about to be opened" ;)
EDIT: I would need also an event notifying that options in a build target or in a project have changed to update the highlighter's data...
The existing cbEVT_PROJECT_TARGETS_MODIFIED is not posted when I change compiler (or other) options in a target or project (in fact no event is posted at all).
The solution of reading compiler options from the active build target every time highlighter is invoked is not elegant and poses problems with wxExecute that I already mentioned
(that is, on C::B startup, wxExecute in OnEditorOpen event handler messes up the UI: image attached; I observed that loading some plugin or changing a little bit UI fixes the layout).
[attachment deleted by admin]
MortenMacFly:
I'm afraid I don't really understand. When you load a project, C::B does not load all files, so there is no such event you are asking for. If you are interested in parsing all files when the project is opened, you need the EVT_PROJECT_OPEN or better EVT_PROJECT_ACTIVATE. Then, in addition you can use EVT_PROJECT_TARGETS_MODIFIED, EVT_PROJECT_FILE_CHANGED, EVT_PROJECT_FILE_ADDED and EVT_PROJECT_END_REMOVE_FILES to check for changes in the setup. There is EVT_SETTINGS_CHANGED for checking, if the project's settings have been changed.
However, it makes no sense to prepare semantic highlighting for files that are actually not really opened, a.k.a. shown as an editor. Imagine you have workspaces with several 1000 files - how long shall the user wait? So semantic highlight IMHO gets interesting, once you see a file in an editor, that's why I pointed you to the EVT_EDITOR_ACTIVATED event.
Have a look at the Code::Completion plugin. It does all that: Checking for project settings, checking for file changes, running external tools (like the compiler to query the compiler's internal settings), workign once a file is opened and so on. CC would not work if all that was not possible.
If you still believe you need more, provide patches. The one you provided does not help you much, it is the same as the EVT_EDITOR_ACTIVATED event, once you did the changes as I suggested. Maybe I'll understand better your needs if you show what you have in mind.
For the wxExecute issue: Run it as an external process, use the C::B SDK to do so, maybe even in a thread. then you won't have such issues. It works really nice in several plugins we already ave, so I see no reason why it should not work for you, except you might have done something wrong. Again: in that case provide a test case / sample to reproduce.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version