Developer forums (C::B DEVELOPMENT STRICTLY!) > Plugins development
Semantic highlight
MortenMacFly:
--- Quote from: mistar on May 19, 2012, 02:17:50 pm ---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.
--- End quote ---
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.
--- Quote from: mistar on May 19, 2012, 02:17:50 pm ---PS. I've checked that EVT_SETTINGS_CHANGED is not posted when a target's settings are changed...
--- End quote ---
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:
--- Quote from: oBFusCATed on May 19, 2012, 02:54:21 pm ---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.
--- End quote ---
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:
--- Quote from: oBFusCATed on May 19, 2012, 02:54:21 pm ---
--- Quote from: mistar on May 19, 2012, 02:46:09 pm ---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
--- End quote ---
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 :)
--- End quote ---
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.
--- Quote from: MortenMacFly on May 19, 2012, 03:07:59 pm ---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.
--- End quote ---
This is a place to add EVT_EDITOR_EXTERNAL_CHANGE or-something-like-this event. C::B should responsible for reloading the text...
--- Quote from: MortenMacFly on May 19, 2012, 03:07:59 pm ---
--- Quote from: mistar on May 19, 2012, 02:17:50 pm ---PS. I've checked that EVT_SETTINGS_CHANGED is not posted when a target's settings are changed...
--- End quote ---
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.
--- End quote ---
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.
--- Quote from: MortenMacFly on May 19, 2012, 03:09:19 pm ---
--- Quote from: oBFusCATed on May 19, 2012, 02:54:21 pm ---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.
--- End quote ---
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...
--- End quote ---
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:
--- Quote from: mistar on May 19, 2012, 03:36:23 pm ---This is a place to add EVT_EDITOR_EXTERNAL_CHANGE or-something-like-this event. C::B should responsible for reloading the text...
--- End quote ---
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:
--- Quote from: MortenMacFly on May 19, 2012, 04:30:05 pm ---
--- Quote from: mistar on May 19, 2012, 03:36:23 pm ---This is a place to add EVT_EDITOR_EXTERNAL_CHANGE or-something-like-this event. C::B should responsible for reloading the text...
--- End quote ---
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.
--- End quote ---
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?
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version