> On Thu, Mar 13, 2014 at 11:42 AM, Dimitar Zhekov
> <dimitar.zhekov@gmail.com>wrote:
>

> + {
>> +  *type = g_strstrip(g_strdup(fields[data->line_idx+2]));
>>
>> Errr, why do you assume that type is always at line_idx+2?..
>>
>
> As far as I could understand, geany parses the error message by gcc

> compiler. gcc compilers have specific error message format [...]

First, there are several build-in parser configurations, with
different separators and field indexes, example messages included. D
and HTML also have warnings.

Second, the examples under "All GNU gcc-like error messages" have only
"filename:line:whatever" is common, and the parser matches that
format. Nowhere is a column assumed, and line_idx+2 may not even
exist. The java examples clearly have type at line_idx + 1.

> http://gcc.gnu.org/onlinedocs/gcc-4.5.0/gnat_ugn_unw/Warning-Message-Control.html#Warning-Message-Control

This is for the gcc Ada compiler, and even if the entire gcc
standartized is standartized at 4.5, the stable debian still contains
gcc-4.4, so it's too early to drop it. And anyway,  Latex will not
gain more fields because the gcc documentation says so...

>> 1. You wrote support for the fallback parser only, and not for regex.
>>
>
> Yes because the regex parser was returning me NULL for c,cpp and java
> files, so I wrote for the fallback parser only. I was unable to find the
> root cause of why the regex parser is returning me NULL for these
> file types.

Well, I can assure you that the regex parser works...

>> 2. This should be considered after either pull request #191 or SF
>> patch #11 is applied. If the PR is chosen, this patch should be fully
>> rewritten as capturing group <W> or something similar.

...*sigh* maybe I should include warning recognition is SF #11, using
your styling code and different recognition.