Thanks Dimitar. Please find my reply below.
On Thu, Mar 13, 2014 at 11:42 AM, Dimitar Zhekov dimitar.zhekov@gmail.comwrote:
- {
- *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...
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...
Thanks Dimitar for clearing things up. I know the error messages do not have standard format and more so it varies a lot from one programming language to another. Also, not every programming language has two types of error messages(warning and error) like C/C++. What I wrote is specific to C/C++ and if the error message has a different format it falls back to the behavior geany currently has.
- 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...
Ok. Let me try again to understand whats going on.
- 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.
Can you please tell me what is SF and PR? Also, can you please assign me a bug or a feature request? I know I can pick anything from the list but since I am new to this project, I think it will be better for me not to chose by myself any bug/feature thats too complicated for me to implement and mess up the code.
Thanks, Shankhoneer Chakrovarty