On Mon, 29 Aug 2011 11:16:05 +1000 Lex Trotman elextr@gmail.com wrote:
Whats anon for? [...]
To have it colored as error or warning. A bit of FX. :)
Bet we get bug reports that users can't click on it :-)
I can trust them that much... :)
Best ::= one of the matches defined as Best, which are unlikely to produce wrong results. Primary purpose: avoid matching against all filetype expressions on build.
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.
Only the regex associated with the command should be used, that is whatever is shown in the configuration GUI for the command.
I know how the project / filetype / default hierarhy works, but should have been more clear:
User regex for the file type ::= project, fallback filetype file
Sorry whats a fallback filetype file? The hierarchy is project filetype setting, user filetype file setting, system filetype file setting, default (is currently blank).
The home filetype or the system filetype file.
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().
I should have been clear that I think that the current behavior is wrong, it should be: if there is a regex use it, otherwise use some default fallback.
The filetype independent (make) commands are the ones that might run into multiple languages. [...] Better to assume developers working with mixed languages are competent enough to select the right expressions and or them together.
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". :)
Why even write a new parser then? With enough | separated patterns, even the current one will work just fine. It would be nice to have warn/anon/copy, but they are only extras.
Well, I am coming to the conclusion after these discussions that you don't need to write a whole new parser (just saved you lots of work :), rather add the ability to use multiple occurrences of named captures to regexes. Without that the | can't work.
With enough | expressions, anything will work. I'll can very long, but a regex limit is 64K...
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.
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.
BTW, how about closing 3039654, and writing some comment for 3156609?
The list model will be removed. Default Messages regex-es plus the plugin defined ones should soffice.
Plugins can't set regexes ATM because none of build.h is in the API, see other thread. This is something to be re-visited.
That's for the Messages only, "On messages tab".
I don't understand what you mean, sorry.
In the Message Window, the "Messages" tab on the left. It's parsing is completely different from the "Compiler" tab.