An alternative to having separate error and warning regexes could be to use separate named captures for error and warning.

Also I didn't find convetions for regexp. For example mapping of group number, type and meaning (e.g groupn:2; meaning:line number; type:integer). I don't think it's a good idea to hardcode such mapping.

The use of the regex is described in the [Geany manual](https://www.geany.org/manual/current/index.html#build-settings-section), it must have two captures, one for the filename and one for the line number. It doesn't matter what order they are since the line number is all digits and the other is the filename.

Since extracting both warning and error information is starting to make the regex more complex I suggest using named captures so the mapping is explicit.

For regex syntax see https://developer.gnome.org/glib/stable/glib-regex-syntax.html and especially section `named subpatterns` (sorry Glib has no anchors to internal sections).

As an example lets run a compiler in a locale called "Faux French" where error messages look like:

``` Erreur:my.file:123: le blah Attention:my.file:456: le more blah ```

a regex like:

``` (?:(?<error>Erreur)/(?<warning>Attention)):(?<file>[^:]+):(?<line>[0-9]+) ```

would provide named matches for the two lines above:

| error | warning | file | line | |--------|------------|------|------| | Erreur | no match | my.file | 123 | | no match | Attention | my.file | 456 |

As you can see only the `error` named capture matches for error messages and only the `warning` named capture matches for warnings, so Geany could use that to tell the them apart without caring what language the contents of the match are in, and `file` and `line` named captures match for both. The other benefit for using named captures is that they can be in any order in the message and never get confused.

Also if the regex did not have named captures the existing method of assuming an all digit capture is line number can still be used, so its backward compatible with any regexes users have already configured.

An keeping to one regex means you don't have to change any GUIS or config file loading or storing, just the code in `filetypes_parse_error_message()` to use the new regexes.

BTW it seems that backreferences do not support named groups.

From the glib regex syntax description:

``` Back references to named subpatterns use the Perl syntax \k<name> or \k'name' or the Python syntax (?P=name). ```

but I admit its not easy to find. And named back references are also numbered too of course.

I think I should document this convetions at least as a comment for filetypes_parse_error_message

Don't worry I will hound you to document it adequately in the manual before the PR will get accepted, erm I mean _help_ you of course :)

IMHO the hard coded error parsing really should not be encouraged any more due to its limitations, lack of maintenance and failure to support newer tools.

It seems that glib isn't able to fetch named subpatterns inside groups line: `main.c:5:2: error: 'a' undeclared (first use in this function)` regex: `(?<file>[^:]+):(?<line>[0-9]+):([0-9]+): ((?<error>error)|(?<warning>warning)).+`

`g_match_info_fetch_named_pos` returns false.

@Yanpas pushed 1 commit.

e6af531 fix named subpattern finding

Oooooh, its just your test file, I thought you were getting the error compiling Geany :)

Well, the indicators come from any build, not just compilers, so I would suggest "Remove Build Indicators"

This will close/fix #447 when merged.

What do you mean?

I do not working on it since there are no updates and tasks to do in this PR. If geany's team is willing to merge it I will resolve the conflicts.

OK, will handle it

@Yanpas pushed 1 commit.

2ca4fe13a3c2a9d9443442aec47202089f1ef921 warning, regex support