Thats easy to avoid, don't do it :)
Yes, it can be easily avoided by by writing the expressions to require one of the known extensions for the file type, and classifying the filename-line-column match as "Good". So the "Best" becomes absolute.
Good point, the expression could handle multiple extensions too, eg ^(?<file>.+?(?:cpp|hpp|h|cxx|hxx)):(?<line>\d+):(?<col>\d+)? this makes it deterministic.
[...]
What is the "default (is currently blank)"?.. I searched Geany for global fallback expression(s) short time ago, but all I could find was parse_compiler_error_line().
Sorry, build_get_regex() used to also look at default, but I forgot it got removed.
[...]
I imagine myself navigating thru the build dialog, copy-pasting all filetype expressions that can be relevant to the project, for every project. And then changing all of them on each slightly different outout... And then I'll finally sit back and say: "There is nobody to blameth, cause I brouth this on myself". :)
Indeed, but its better that shouting, "Where the [long string of expletives deleted] is it getting that from ..." :-)
[...]
With enough | expressions, anything will work. I'll can very long, but a regex limit is 64K...
Just how many languages do you mix? You only need the ones you use in the project. Most sane people tend to limit themselves to only a few, one or two code plus one or two documentation. Like Geany does. People who don't limit themselves become insane :-D
Then if you really want the fun, the fallback when no regex is specified could be upgraded from the current hardcoded routine to use your multiple language search, best match, super dooper[1] technology, but with a preference to turn it on/off in case it produces unwanted results.
You saved me even more work. With a single regex defined in 54 system filetypes, and 4 mentions of the message parsing in 1320 tracker items, It odesn't look like anybody needs a new parser, much less anyone is going to define complex new-style regex-es.
Good analysis, as I said in the past, there is only a single filetype regex because the hard coded method came first and no-one has had time to change anything. Its not because they think the current system is best.
Of course we don't know how many user defined regexes are out there working perfectly and silently.
So I'd better head to more practical things: column support and optional underlining for the Messages tab, and optional mark all Find Usage matches.
Well, using named captures and so allowing multi-language regexes is a useful improvement. Having to select a C++ file before building is annoying (Python only throws one error at a time so its better to get the C++ errors parsed). The named captures also helps your column support be more robust.
BTW, how about closing 3039654, and writing some comment for 3156609?
Sure, I'm currently behind a corporate firewall which doesn't let me login to sourceforge (or the wiki) and looks like being another couple of weeks before I'm finished. So if someone else wants to close the first and note on the second that the documentation already says new entries override old ones, see http://www.geany.org/manual/current/index.html#old-settings then it won't be forgotten, thanks.
[...]
In the Message Window, the "Messages" tab on the left. It's parsing is completely different from the "Compiler" tab.
Ahhh, I had forgotten that the messages window parsed anything.
Cheers Lex