[Geany-Devel] Hi!

Shankhoneer Chakrovarty shankhoneer at xxxxx
Tue Mar 18 16:26:54 UTC 2014

Thanks Dimitar.
Please find my reply below.

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

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.

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

Ok. Let me try again to understand whats going on.

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

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.

Shankhoneer Chakrovarty
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.geany.org/pipermail/devel/attachments/20140318/aba5f0e3/attachment.html>

More information about the Devel mailing list