Preprocessing and scintilla_22

[jfouche]

need to improve it in order ta manage complexe #ifxxx definitions.

What do you mean by "complex" definitions?

Code: Select all

#if defined(BAR)
	//
#endif

#if defined(__WXMSW__) && defined(__X__)
	//
#endif

[jfouche]

- Once the parse is done, an event is sent back to the editor (the requested file name is sent back with teh event to make sure that the calling editor is still opened)
- If the requesting editor is "still alive" the macros are then "feed" into scintilla

I understand what you mean, but I don't know how to achieve it. I didn't fond a way to know if the given editor is still alive. A clue would be helpfull

[eranif]

Use the file name.

The ParseRequest class has a member '_file'
When you send back the event with the list of the macros from the parse thread to the main thread, include the original file name in the reply as well.
This way in the event handler function we can check whether the file with this given name is opened, if not - discard the reply.

Use this API call:

Code: Select all

LEditor *MainBook::FindEditor(const wxString &fileName);

if an editor with this filename exists, then use it (it does not really matter if it is the same LEditor instance, we only care that it will contain the correct file)

Eran

[jfouche]

What is the event handler relative to the main thread you're talking about ? wxTheApp, MainFrame, Manager, ... ? My first thought was to send it back to the LEditor itself, but it's definitly not the good way.

[eranif]

You should use one of the "persistent" objects in codelite for this event rather than the transient widgets (like LEditor)

I would go for either for the Manager / clMainFrame / MainBook.

I would do it like this:
- Add new event 'wxEVT_EDITOR_LOADED'
- Handle this event in the Manager::OnEditorLoaded
- Prepare the ParseThread event and 'Add' to the parse thread queue (set Manager as the _eventHandler)
- When the processing is done handle it in Manager::OnMacrosCollectDone (or something more creative than that )
- search for the editor by calling clMainFrame::Get()->GetMainBook()->FindEditor( <name> ) if the editor exits, do your logic

Eran

[jfouche]

I was thinking about something :
Because of the way we took, if the user is writting an ifdef macro, it will stay grayed, even if the macro is defined, because we decided not to keep it during the analysis. So, we will need to refresh (eg call this ParseThread) more time than only during editor loading. But this task can take time.
An other idea would be to keep all macros in a DB cache, and only analyse used macro in a file which is pretty fast. We could do this more often than the whole big task of include search, PPScan for each inc, PPScan of the current file, and retrieve only macros in both sections. The work shall be to update this cache during a file saving :

Table DefMacros
- name
- value
- filename

To find the interresting macros, we just need to select name, value from DefMacros where name in (...) which is very fast.
To update DB when a file is saved (or during a workspace retaging), we just need to delete where filename is ..., and insert the scanned file (which is fast also). This way, I think we could call this more often, and offer the user a more up to date editor.

Well, this is big changes, so what do you think ?

[eranif]

We could add another table to the database, and use those instead. this means integrating this stage in the standard parsing phase, there is already a PPScan call during that stage, its that we only pick macros with the form of function (since those are needed for code completion)

So each time a file is saved, we need to parse and store the macros into the database.
When the file is loaded we need to parse the current file only and cross it with the database from the database.

We also need to refresh the macros list when an editor is selected
Eran

[jfouche]

Hi Eran

Here is a summary of the design (just a remainder for me, as I will not be available for a few days to work on this) :

1 : Update DB model
* Add a table MACROS_DEF (question : what about the existing MACRO table ? Can we merge it ?) -> tags_storage_sqlite.cpp

2 : Update this table during workspace retag

3 : When a file is loaded, PPScan it (not for CC) in order to know macros used -> select name, value from MACROS_DEF where name in (used macros). Add a new event handler in Manager in order to handle the result. Update the editor if still existing.

4 : Call it also when the user entered ... what ? Regex to know if the line entered match an #if / ifdef / ifndef ? maybe to time consumming... At least, when saving a file, and when an editor is selected.

[eranif]

(question : what about the existing MACRO table ? Can we merge it ?)

this table contains only macros which are 'function like'
better to create new table, otherwise it will affect the code completion speed.

Call it also when the user entered ... what

Nothing.

There should be "refresh" in the following scenarios:
- File loading
- Editor is "selected"
- File save - update the macros table. However there is no need to refresh the current editor (see note below)

Note that if you add new macro the current file, it will be pre-processed by scintilla automatically. Scintilla only needs of macros which are defined elsewhere and not in the current file.
We need to refresh editor when it is selected, since a new macro may be added in another editor which is also opened

Eran

[jfouche]

Note that if you add new macro the current file, it will be pre-processed by scintilla automatically. Scintilla only needs of macros which are defined elsewhere and not in the current file.

I know about this. I was talking about the use (not the definition) of a macro :

Code: Select all

...
#ifdef FOO|

where | is the caret position.

We must ask database if FOO exists, because we didn't ask before (so we supposed that it was not an interesting macro). But in fact, after entered some text, it is an interesting macro. You see what I mean ?