Semantic highlight

[mistar]

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.

I do not want to scan all project's files
But I really don't see why is EVT_EDITOR_ACTIVATED the same as EVT_EDITOR_OPENED/LOADED...
I need to 'process' a file whenever a tab for this file appears in the C::B tab bar and 'process' this file when its tab disappears.
This is exactly what you said: I do not need to process files that are not displayed as tabs (aka opened in my terminology).
EVT_EDITOR_ACTIVATED is posted every time an editor gets focus and this is not what I need (or I really don't understand you...).
By 'process' I mean (among others) getting the project the file belongs to (which cannot be done using EVT_EDITOR_OPEN)
to get compile options.

But you are right, I'll have a look at CC plugin...

PS. I've checked that EVT_SETTINGS_CHANGED is not posted when a target's settings are changed...

[oBFusCATed]

Why do you need this?
I think you need something like EVT_EDITOR_MODIFIED event*, so you get a notification, when the contents of the editor gets modified.

At the start you'll do the first pass on EVT_EDITOR_ACTIVATED and mark it as highlighted, then when you get a modified event you'll do the re-highlighting...

* If there is no such event you can add it easily I think, just make sure you don't fire it for every key press.
Probably you can use a timer and group multiple changes together...

p.s. and don't forget to test the performance with massive files 30-40k lines of code

[mistar]

Why do you need this?
I think you need something like EVT_EDITOR_MODIFIED event*, so you get a notification, when the contents of the editor gets modified.

At the start you'll do the first pass on EVT_EDITOR_ACTIVATED and mark it as highlighted, then when you get a modified event you'll do the re-highlighting...

This is an idea, but I don't like it because every time I catch EVT_EDITOR_ACTIVATED I search some set of editors for the one I am processing...
I really don't understand your reluctance in introducing new events
If some things are natural and allows for better performance why not introduce them?
BTW: why don't you program in C? Why people introduced C++? After all, you can do everything in pure C or better, assembly or pure machine code ;P

[MortenMacFly]

* If there is no such event you can add it easily I think, just make sure you don't fire it for every key press.
Probably you can use a timer and group multiple changes together...

cbEVT_EDITOR_MODIFIED

We have them all... ;-)

[oBFusCATed]

BTW: why don't you program in C? Why people introduced C++? After all, you can do everything in pure C or better, assembly or pure machine code ;P

What is this comment? Something serious or just a joke?

BTW: I have no problem adding new events, but I don't understand the logic behind the current system, so I can't comment if your proposal is good or not, I'm just telling you what would I do if I'm implementing you.
BTW2: If you use a hash table there would be no performance problems

[MortenMacFly]

I do not want to scan all project's files
But I really don't see why is EVT_EDITOR_ACTIVATED the same as EVT_EDITOR_OPENED/LOADED...
I need to 'process' a file whenever a tab for this file appears in the C::B tab bar and 'process' this file when its tab disappears.
This is exactly what you said: I do not need to process files that are not displayed as tabs (aka opened in my terminology).
EVT_EDITOR_ACTIVATED is posted every time an editor gets focus and this is not what I need (or I really don't understand you...).
By 'process' I mean (among others) getting the project the file belongs to (which cannot be done using EVT_EDITOR_OPEN)
to get compile options.

Aha - I guess I understood what you mean now. But keepin mind, that the file might have changed externally and this is checked only at the EVT_EDITOR_ACTIVATED IMHO. So to make sure you are getting the up-to-date file content, this event is still right for you. You could use some caching to avoid scanning if not really needed. However, I still think adding another event would be an overkill as you can do what you want with the events we have. But if you really insist... nag me again and I'll see.

PS. I've checked that EVT_SETTINGS_CHANGED is not posted when a target's settings are changed...

That is true, it fires only when the global setting are changed. In your use case, you might want to check EVT_BUILDTARGET_SELECTED or EVT_PROJECT_TARGETS_MODIFIED.

[MortenMacFly]

BTW: I have no problem adding new events, but I don't understand the logic behind the current system, so I can't comment if your proposal is good or not, I'm just telling you what would I do if I'm implementing you.

Do we actually have a good documentation about the events present? WiKi / SDK help?

BTW: there is the EventsDisplay plugin somewhere in the forums that shows them all...

[mistar]

BTW: why don't you program in C? Why people introduced C++? After all, you can do everything in pure C or better, assembly or pure machine code ;P

What is this comment? Something serious or just a joke?

BTW: I have no problem adding new events, but I don't understand the logic behind the current system, so I can't comment if your proposal is good or not, I'm just telling you what would I do if I'm implementing you.
BTW2: If you use a hash table there would be no performance problems

Note the ";P" at the end.

I'd just like to propose some changes that facilitate some actions.
By introducing an event that is well suited for some things, you (people) make my (as well as other's) code more maintainable.
Otherwise more and more code will be just a workaround, the entire logic will eventually be lost and you end up with redesigning some things
(which is far more time-consuming than adding new, natural events).

As for hash tables, they have expected constant time complexity; but this doesn't mean that I refrain from using them.

My logic behind SH plugin is:
Editor is opened => if c++ file, create an index and highlight the text (with compile options of the editor's project's active build target via 'Target->CompileOptions' map described below)
Editor is closing => if c++ file, destroy an index
BuildTarget is created or modified => get compile options of the target, execute those in `...` and add it to a map 'Target->CompileOptions'
BuildTarget is removed => remove options from the map.
Source file changed (I have a framework for this already) => reparse index (here enter some optimizations from clang, e.g. precompiled headers) and highlight the text.
That's all. Just a simple logic.

Aha - I guess I understood what you mean now. But keepin mind, that the file might have changed externally and this is checked only at the EVT_EDITOR_ACTIVATED IMHO. So to make sure you are getting the up-to-date file content, this event is still right for you.

This is a place to add EVT_EDITOR_EXTERNAL_CHANGE or-something-like-this event. C::B should responsible for reloading the text...

PS. I've checked that EVT_SETTINGS_CHANGED is not posted when a target's settings are changed...

That is true, it fires only when the global setting are changed. In your use case, you might want to check EVT_BUILDTARGET_SELECTED or EVT_PROJECT_TARGETS_MODIFIED.

This is similar to using EVT_EDITOR_ACTIVATED instead of EVT_EDITOR_OPENED... just a workaround (or 'ugly hack' )
And the real problem is that no event is posted at all after changing compiler options.

BTW: I have no problem adding new events, but I don't understand the logic behind the current system, so I can't comment if your proposal is good or not, I'm just telling you what would I do if I'm implementing you.

Do we actually have a good documentation about the events present? WiKi / SDK help?

BTW: there is the EventsDisplay plugin somewhere in the forums that shows them all...

Wiki is not up-to-date (hence I didn't realize that EVT_SETTINGS_CHANGED exists) but the sources are sufficient.

I am using DisplayEvents after updating its events database

[MortenMacFly]

This is a place to add EVT_EDITOR_EXTERNAL_CHANGE or-something-like-this event. C::B should responsible for reloading the text...

Sure, and it does exactly that. What I meant is if you only listen to editor open, then this is not enough for such cases, including the user edited the file a lot (including "hard-core" like selecting all text and removing it). So how will you track these changes? I strongly believe EVT_EDITOR_OPENED is not enough to cover all these cases, however, EVT_EDITOR_ACTIVATED in addition to EVT_EDITOR_MODIFIED will do. So I don't think this is an ugly hack, but the way to go. In the end, if a user opened a file (EVT_EDITOR_OPENED is fired) it is because in 99% of the time the content of the editor will change. So whatever you get at the time EVT_EDITOR_OPENED fires is obsolete sooner or later.

My proposal therefore: Add the event you desire in your local copy as needed and provide it as a patch with the plugin sources. If all works out nicely we / I will add it officially to the SDK.

[mistar]

This is a place to add EVT_EDITOR_EXTERNAL_CHANGE or-something-like-this event. C::B should responsible for reloading the text...

Sure, and it does exactly that. What I meant is if you only listen to editor open, then this is not enough for such cases, including the user edited the file a lot (including "hard-core" like selecting all text and removing it). So how will you track these changes? I strongly believe EVT_EDITOR_OPENED is not enough to cover all these cases, however, EVT_EDITOR_ACTIVATED in addition to EVT_EDITOR_MODIFIED will do. So I don't think this is an ugly hack, but the way to go. In the end, if a user opened a file (EVT_EDITOR_OPENED is fired) it is because in 99% of the time the content of the editor will change. So whatever you get at the time EVT_EDITOR_OPENED fires is obsolete sooner or later.

My proposal therefore: Add the event you desire in your local copy as needed and provide it as a patch with the plugin sources. If all works out nicely we / I will add it officially to the SDK.

I am using EVT_EDITOR_OPENED only to set up data for that editor, like libclang's index and translation unit and to do initial highlighting.
It is better to do it during opening a file (since it may take longer than just reparsing text being edited, even 5-10 seconds with huge amount of headers pulled in)
than during first key press...
I understand that I can do it using EVT_EDITOR_ACTIVATED, but this way, first I must check whether it is first activation of the editor or not and this is code pollution IHMO
I'm far from forcing you to add new events. I just think that adding adequate events will make C::B sources more clear...
BTW, there are plenty of events like ...BEFORE_SAVE, ...SAVE, and so on... so why not BEFORE_OPEN and OPEN?
And, what is a purpose of EVT_EDITOR_OPEN then? why not to use EVT_EDITOR_ACTIVATED instead with workarounds?

[MortenMacFly]

And, what is a purpose of EVT_EDITOR_OPEN then? why not to use EVT_EDITOR_ACTIVATED instead with workarounds?

I told you already, what this event is for. A lot plugins make use of this that need to track editors, like the ReopenEditor plugin (have a look). Here, for a file list for example, the ACTIVATED event is not important. It is also important to intercept opening editors that are no text editors.

Again: I am not against adding another event, its just that I am not fully convinced it is the right thing to do for your purposes. I might be wrong though - so proof me wrong with your implementation / patch.

[mistar]

Again: I am not against adding another event, its just that I am not fully convinced it is the right thing to do for your purposes. I might be wrong though - so proof me wrong with your implementation / patch.

OK, I'll try

[mistar]

I have read all your posts, guys, and come to a conclusion that you don't read my posts at large
Just an example:

What I meant is if you only listen to editor open, then this is not enough for such cases, including the user edited the file a lot (including "hard-core" like selecting all text and removing it). So how will you track these changes? I strongly believe EVT_EDITOR_OPENED is not enough to cover all these cases, however, EVT_EDITOR_ACTIVATED in addition to EVT_EDITOR_MODIFIED will do. So I don't think this is an ugly hack, but the way to go. In the end, if a user opened a file (EVT_EDITOR_OPENED is fired) it is because in 99% of the time the content of the editor will change. So whatever you get at the time EVT_EDITOR_OPENED fires is obsolete sooner or later.

just after I wrote

My logic behind SH plugin is:
Editor is opened => if c++ file, create an index and highlight the text (with compile options of the editor's project's active build target via 'Target->CompileOptions' map described below)
Editor is closing => if c++ file, destroy an index
BuildTarget is created or modified => get compile options of the target, execute those in `...` and add it to a map 'Target->CompileOptions'
BuildTarget is removed => remove options from the map.
Source file changed (I have a framework for this already) => reparse index (here enter some optimizations from clang, e.g. precompiled headers) and highlight the text.
That's all. Just a simple logic.

I haven't written anywhere that I will use EVT_EDITOR_OPENED to track changes in source code...
I want to use it to do some initializations for an editor that has just been opened then some event(s) to track changes and then EVT_EDITOR_CLOSE to clean up SH data for the editor.
Just as simple as Constructor/Destructor logic.

BTW, EVT_EDITOR_MODIFIED is not for tracking changes... it is fired when an editor flips its state to/from modified (with an asterisk prepended to the file name);
neither is EVT_EDITOR_UPDATE_UI good for this.
I do have a framework for tracking changes, and all I need is to do initializations.
Now I'll try to use EVT_EDITOR_ACTIVATED though I still believe this is not the right event to do this...

And please, don't get we wrong, I'm here not to criticize you. You've made great work to get C::B to work and I really appreciate it!
I just believe that couple of things I propose make the sources of C::B and also of my plugin more clear.

[MortenMacFly]

I just believe that couple of things I propose make the sources of C::B and also of my plugin more clear.

Sure thing - that's why I encouraged you do it the way you believe is best for you (and clean code) and provide patches to the core if necessary.

[mistar]

Hi guys!
I'm almost done with the very basic real-time semantic highlighter (first parsing is quite slow, that is, 4s but next ones highlight sources quite fast, i.e., below 0.5s on my Pentium Dual-Core machine). The plugin crashes sometimes so I'm not going to attach the sources, but I'm working on it

I'm using EDITOR_ACTIVATED event (I realized that it is necessary to re-highlight an editor on each editor switch to ensure changes made in other files take effect) so there is no big need for EDITOR_OPENED patch as for now

What is left:
* fix bugs so that the plugin does not crash;
* add events that are posted on compiler options change (I'll need a little bit of your help here);
* write configuration panel (as for now I'm using fixed colors);