Semantic highlight

[mistar]

Hi guys.

I'm working on C::B plugin for semantic highlight based on clang.
For a long time I've used Eclipse CDT but its support for the new c++11 standard (which I'm using extensively) is quite poor...

Currently I'm designing a framework for SemanticHighlight plugin and have following problems:

1. The member function CodeBlocksEvent::GetEditor() returns a pointer to EditorBase, not to cbEditor; hence the static_cast in the code below;
2. when I handle cbEVT_EDITOR_OPEN event:

Code: [Select]

void SemanticHighlight::OnEditorOpen(CodeBlocksEvent & evt)
{
    cbEditor * ed = static_cast<cbEditor *>(evt.GetEditor());
    ProjectFile * pf = ed->GetProjectFile();
    wxString projTitle = pf ? pf->GetParentProject()->GetTitle() : wxT("[None]");
    Manager::Get()->GetLogManager()->Log(wxT("\tSH: processing cbEVT_EDITOR_OPEN: ")+evt.GetEditor()->GetTitle()+wxT("@")+projTitle);
}
the variable 'ed' is always set to null pointer regardless of whether the opened file has parent project or not.

Isn't it a bug?

EDIT: I'm using the latest nightly build on Gentoo Linux

[oBFusCATed]

Sorry to disappoint you but currently you won't be able to implement such plugin.
And the reason is that the editor control we are using doesn't support it.
We are using Scintilla (wxScintilla to be exact).
If you look at their mailing list you'll find info of other people trying to do it and you'll be able to read about their failures.

Here is the link to the discussion: http://groups.google.com/group/scintilla-interest/browse_thread/thread/35a1ba3c99488d8f/b7365d210b6aca39?hl=en&lnk=gst&q=semantic+highlight#

For the cast, you can test the EditorBase if it is a built in editor, then the cast is safe.

[mistar]

Sorry to disappoint you but currently you won't be able to implement such plugin.
And the reason is that the editor control we are using doesn't support it.
We are using Scintilla (wxScintilla to be exact).
If you look at their mailing list you'll find info of other people trying to do it and you'll be able to read about their failures.

Here is the link to the discussion: http://groups.google.com/group/scintilla-interest/browse_thread/thread/35a1ba3c99488d8f/b7365d210b6aca39?hl=en&lnk=gst&q=semantic+highlight#

For the cast, you can test the EditorBase if it is a built in editor, then the cast is safe.

I know you are using Scintilla. I believe it has ability to manually set styles (without use of any lexer),
so the only thing is to correctly assign semantic information to tokens.
It is by no means the cleanest way to do it but the effect can be even better than that of SH in Eclipse CDT.
Nota bene, semantic highlighting _cannot_ use lexers as a token might have different semantics in different contexts (e.g., namespaces).

What about cbEVT_EDITOR_OPEN? In cbEVT_EDITOR_CLOSE everything is ok...
Besides, why is cbEVT_EDITOR_OPEN posted before cbEVT_PROJECT_OPEN when loading recently-opened files? This is really weird...

Thanks for pointing out EditorBase::IsBuiltinEditor

[mistar]

OK, I've found the reason...

Why is cbEVT_EDITOR_OPEN event posted in EditorManager::New instead of EditorManager::Open (after cbEditor::SetProjectFile is called)?
BTW, can someone explain why are cbEVT_EDITOR_* events to be posted for non-builtin editors?
Thanks in advance!

[ollydbg]

Your work is very promising. Great! I'm also interest on this. I see there are some document of scintilla about writing custom lexers which can set colors of the text by clients. Maybe I'm wrong. 

Here are some resources/links you may interest:
1, Clang code completion: ClangComplete plugin
2, Display Events: DisplayEvents plugin - CodeBlocks

[mistar]

For semantic highlight one cannot use lexers, but there is an option to style a given text manually in Scintilla.
I don't suspect it to be efficient but it should be anyway more efficient than semantic highlight in Eclipse CDT.

BTW, C::B is great IDE but its sources are messy... It lacks a good framework (design).
Some examples I've mentioned above and another one I encountered when I wanted to get a project's active build target:
GetActiveBuildTarget returns a wxString and there is no option to get an index or pointer...
IHMO, the right way is to get a pointer to a build target object and then to obtain a wxString just call one of the BT methods...

So... Did you, C::B guys, consider redesigning C::B SDK API and then redesigning plugins?

More complaints to come ;P

[oBFusCATed]

If you want to invest the time and do it and you show us that your changes improve the API,
why not, but don't expect anyone to take the job.

p.s. You can get a target by name, I think, if think there is a better way, post a patch

[mistar]

Ok, guys.
If you are interested, in two or three weeks I'll be done with SemanticHighlight plugin provided the problem with cbEVT_EDITOR_OPEN will be solved.
To finish SH plugin, I _really_ need to get the project a file belongs to because I need to get all the project's include directories and defines to get SH plugin work properly.
Since I am new to C::B sdk, I'd like someone to take a look at this proposal of change in the file editormanager.cpp:

remove these lines from EditorManager::New():

Code: [Select]

CodeBlocksEvent evt(cbEVT_EDITOR_OPEN, -1, 0, ed);
Manager::Get()->GetPluginManager()->NotifyPlugins(evt);
and insert these lines to EditorManager::Open(LoaderBase*, const wxString &, int, ProjectFile *):

Code: [Select]

if (!eb) // was not open
{
  CodeBlocksEvent evt(cbEVT_EDITOR_OPEN, -1, 0, ed);
  Manager::Get()->GetPluginManager()->NotifyPlugins(evt);
}
just before "s_CanShutdown = true". This way, cbEVT_EDITOR_OPEN is posted after all editor's data is initialized.

[MortenMacFly]

Why is cbEVT_EDITOR_OPEN event posted in EditorManager::New instead of EditorManager::Open (after cbEditor::SetProjectFile is called)?

Because it is defined as "about to be opened" if you like and plugins can intercept and interrupt this event in case they handle the file itself. So this won't change.

If you need another event after the file has been opened and added to the project, you would need another (new) SDK event, like cbEVT_EDITOR_OPENED. Implement this and provide a patch and it may make it into C::B's core.

[mistar]

Thanks for your reply.

Since I've never participate in a big project like C::B, please guide me what to do to post a patch (I've searched the forum but dodn't find anything),
or point to some description.

My proposal:
1. insert the code below to EditorManager::Open(LoaderBase*, const wxString &, int, ProjectFile *) in editormanager.cpp:

Code: [Select]

if (!eb) // was not open
{
  CodeBlocksEvent evt(cbEVT_EDITOR_OPENED, -1, 0, ed);
  Manager::Get()->GetPluginManager()->NotifyPlugins(evt);
}
just before

Code: [Select]

s_CanShutdown = true;
2. Declare new sdk editor event cbEVT_EDITOR_OPENED (or maybe _LOADED?) in sdk_events.h:

Code: [Select]

extern EVTIMPORT const wxEventType cbEVT_EDITOR_OPENED;
#define EVT_EDITOR_OPENED(fn) DECLARE_EVENT_TABLE_ENTRY( cbEVT_EDITOR_OPENED, -1, -1, (wxObjectEventFunction)(wxEventFunction)(CodeBlocksEventFunction)&fn, (wxObject *) NULL ),
3. Define cbEVT_EDITOR_OPENED in sdk_events.cpp

Code: [Select]

const wxEventType cbEVT_EDITOR_OPENED = wxNewEventType();
4. Add

Code: [Select]

NotifyPlugins(cbEVT_EDITOR_OPENED);to cbEditor::Open() in cbeditor.cpp.

[Alpha]

Since I've never participate in a big project like C::B, please guide me what to do to post a patch (I've searched the forum but dodn't find anything),
or point to some description.

Creating a patch to submit to BerliOS (Patch Tracker)

[mistar]

Since I've never participate in a big project like C::B, please guide me what to do to post a patch (I've searched the forum but dodn't find anything),
or point to some description.

Creating a patch to submit to BerliOS (Patch Tracker)

Thanks!
Patch submitted. How long does it take on average to incorporate the changes?

[perento]

Hello mistar, may i ask what functions the plugin will be offered?

[MortenMacFly]

Patch submitted. How long does it take on average to incorporate the changes?

Well, I had a look at this.

I think there is a better way: Instead of introducing another event, you could move the portion:

Code: [Select]

   if (can_updateui)
    {
        if (ed)
        {
            SetActiveEditor(ed);
            ed->GetControl()->SetFocus();
        }
    }
...to after:

Code: [Select]

   // 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);
    }
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...).

[MortenMacFly]

Why is cbEVT_EDITOR_OPEN event posted in EditorManager::New instead of EditorManager::Open (after cbEditor::SetProjectFile is called)?

Because it is defined as "about to be opened" if you like and plugins can intercept and interrupt this event in case they handle the file itself. So this won't change.

BTW: This was wrong. This event fires when a file has either been created (so it is new from scratch) or newly opened, like File -> Open -> "...". The latter is the reason why it is called OPEN. Internally it means C::B creates a new editor and also loads the file into memory (as needed).