Version 0.2
1. A message is parsed using a GRegex with the following subpaterns:
file file name, must match a non-empty text if defined line line #, must match a number if defined col column # warn Compiler only: if matched with non-empty text, the entire message is a warning rather than an error anon an error or warning message not related to a particular file; must not be specified with file or line, of course copy if matched with non-empty text, context menu Copy will copy that text instead of the entire message
All subpaterns are optional.
If none of file, line or anon is defined, Geany will read the first two (or three, if there is a third) matches, and check whether the first or second match is purely digits. If so, it'll try to use the matches as <line> [column] <file>, or as <file> <line> [column].
2. The following expressions are attempted:
On compile:
The best match regex from the previous line, if any (see below). User regex for the file type. Default regex for the file type. User independent commands regex.
On build:
All compile regex-es. All user regex-es for other file types. All default regex-es for other file types.
On messages tab (examples, subject to change):
Any plugin-defined regex-es. (?<file>[^:]+):(?<line>[0-9]+)(?:[:,](?<col>[0-9]+))?\W (?<file>[^)]+)(?<line>[0-9]+)(?:,(?<col>[0-9]+))[\W\D]
3. Maching quality:
Best: file with one of the known extensions for the file type, or file, line an column. Once such a match is found, no more expressions are attempted.
Average: file and line.
Weak: one of file, line or anon. Be sure not to specify too generic expressions.
No match: none of file, line or anon.
4. Recommendations for writing regular expressions:
Read GLib Reference Manual, Regular expression syntax.
For more precise parsing, try to match the start or end of line, or some unambigous text.
Exclude the delimiter following a subpattern: "[^:]+:" instead of ".+:" (note that Geany assumes colon-less document names), or use (?U) for non-greedy matching.
5. Initial implementation:
The default compiler expressions will match the current behaviour of parse_compiler_error_line(), with some small improvements. More precise regex-es should be written.
The list model will be removed. Default Messages regex-es plus the plugin defined ones should soffice.
--
On Fri, 26 Aug 2011 11:37:07 +1000 Lex Trotman elextr@gmail.com wrote:
That assumes Geany uses a regex engine that supports named captures, eg GRegex.
Now we're talking! Thanks, Lex.
[:]+ S/B [^:]+ ie "one or more not a :" not "one or more :"
Sure, lapsus keyboardus.
"libtool *--mode=link| from ([:]+):([0-9]+)[,:]([0-9]+[,:])?$"
Needs to escape the * after libtool, plus several instances of the problem in example 1.
The command is "libtool --mode=link", but I've seen it with 2 spaces, so it should actually be " +".