Thanks Dimitar.

On Thu, Mar 13, 2014 at 11:42 AM, Dimitar Zhekov <dimitar.zhekov@gmail.com> wrote:
- data.min_fields = 3;
+ data.min_fields = 5;

Please note that parse_file_line() returns if length(fields) is less
than data->min_fields. With the above change, anything with < 4 colons
will be rejected.
 
Thanks for pointing out the error. I am now extracting all the tokens and then comparing if number of tokens I have is less than data->min_fields. 

+ if (g_strv_length(fields) == data->min_fields)

N/A: parse_file_line() returns on length(fields) < min_fields, and the
maximum fields to parse are min_fields, so length(fields) is always
equal to min_fields at this point.

Thanks for pointing that out, I have made the corrections
 
 
+ {
+  *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 (http://gcc.gnu.org/onlinedocs/gcc-4.5.0/gnat_ugn_unw/Warning-Message-Control.html#Warning-Message-Control) which is of the form <filename>:<line number>:<column number>:<warning.error>:<message>. This format guarantees that 2 fields after <line number> will be <warning/error>. So I used line_idx+2 to denote type_idx. I should declare type_idx variable and assign line_idx+2 to it which I think is more maintainable than the current version. What do you think?

--

Finally:

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 filetypes. 

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.

Thanks,
Shankhoneer Chakrovarty