Thanks Dimitar.
On Thu, Mar 13, 2014 at 11:42 AM, Dimitar Zhekov dimitar.zhekov@gmail.comwrote:
- 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...) 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:
- 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.
- 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