Multiple patterns for err/warn

[jfouche]

Hi Eran

I started to work on the support for multiple regex for errors / warnings. As written on the RoadMap page (which is impossible to find on the codelite web site... I found it on the forum), I would help you on this point, because I think it's the main problem of CodeLite actualy (but still very usable ). See you with a patch hopefully in a few time.

PS : the new CodeLite web site is cool... but a "search" area is really missing

[eranif]

I started to work on the support for multiple regex for errors / warnings. As written on the RoadMap page (which is impossible to find on the codelite web site... I found it on the forum), I would help you on this point, because I think it's the main problem of CodeLite actualy (but still very usable ). See you with a patch hopefully in a few time.

Thank you! this will shorten the waiting for the next release.

I will add link to the RoadMap in the main page side bar, and I will also re-enable the search box

Eran

[eranif]

PS : the new CodeLite web site is cool... but a "search" area is really missing

Web site is fixed. I also added quick link on the site 'side bar' to the roadmap

Eran

[jfouche]

Good news, it seems to be fine for me. I have to make some tests now (well, tomorow in fact, as I'm going to bed). Then, I have to learn a little bit more about regex to add the missing ones (and find the "not founded" errors / warnings by CodeLite).

Everybody who have some can submit them here. If you can also provide a minimal sample to reproduce the problems, I will be very happy.

[jfouche]

Hi Eran

I would like to have your point of view : Actually, the output tab line parsing begins with warning pattern. If there is no warning, CL tries ta match an error pattern. I think that come from the fact that the actual error pattern matches also warnings ([ eor]*). Can you tell me if you remember why did you choose this pattern instead of ( error) ?
If a line matches both patterns, I suggest to treat that line as an error. This can be done with the new behaviour. The only problem I see, is that it breaks the old user build_settings.xml config file, as the old pattern will see warnings as errors. Is it a problem ?

[edit] : I added the folowing pattern to match some linker errors :

Code: Select all

^([^ ][a-zA-Z:]{0,2}[ a-zA-Z\\.0-9_/\\+\\-]+ *)(:)([0-9]+ *)(:)( undefined reference to)

[jfouche]

Here is the patch, without the linker error pattern.

[edit] I tested also with :

Code: Select all

^([^ ][a-zA-Z:]{0,2}[ a-zA-Z\\.0-9_/\\+\\-]+ *)(:)([ a-zA-Z\\.0-9_/\\+\\-]+ *)(:)(\(.text\+0x[0-9a-f]*\))(:)( undefined reference to)
1
0

Which gives more linker errors (for g++ at least..)

[edit] : removed deprecated patch.

[jfouche]

Eran

Can you tell me how do you manage window size persistance ? Because the dialog i made to add / edit a pattern doesn't keep it's size / position...

[eranif]

In your dialog, add this line:

Code: Select all

WindowAttrManager::Load(this, wxT("MyDialogName"), NULL);

If you want to use this class from within a plugin, the last parameter must not be NULL, but rather like this

Code: Select all

WindowAttrManager::Load(this, wxT("MyDialogName"), m_mgr->GetConfigTool());

And in the dialog destructor, add this line:

Code: Select all

WindowAttrManager::Save(this, wxT("MyDialogName"), NULL);

Eran

[jfouche]

Thanks Eran

Here is a new patch with the window persistance, and a bug fixe for warning pattern update button.

[edit] : removed deprecated patch

[eranif]

Hi Jeremie

I started applying the patches I had in my queue, and it seems that your patch can not be applied after the last chain of patches I just committed.

Can you please update your svn? and recreate the patch?

Thanks!
Eran