Developer forums (C::B DEVELOPMENT STRICTLY!) > Plugins development
Semantic highlight
MortenMacFly:
--- Quote from: mistar on May 19, 2012, 05:01:00 pm ---And, what is a purpose of EVT_EDITOR_OPEN then? why not to use EVT_EDITOR_ACTIVATED instead with workarounds?
--- End quote ---
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. 8)
mistar:
--- Quote from: MortenMacFly on May 19, 2012, 08:21:09 pm ---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. 8)
--- End quote ---
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:
--- Quote from: MortenMacFly on May 19, 2012, 04:30:05 pm ---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.
--- End quote ---
just after I wrote
--- Quote from: mistar on May 19, 2012, 03:36:23 pm ---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.
--- End quote ---
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:
--- Quote from: mistar on May 20, 2012, 11:19:54 am ---I just believe that couple of things I propose make the sources of C::B and also of my plugin more clear.
--- End quote ---
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. :D
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);
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version