On Sun, 28 Aug 2011 15:32:19 +1000 Lex Trotman elextr@gmail.com wrote:
Whats anon for? I guess its nice to make the error red, but we can't click on it to go anywhere since it doesn't have a file so its different to all the other red lines.
To have it colored as error or warning. A bit of FX. :)
- The following expressions are attempted:
If I understand it correctly then I strongly disagree with this section. Trying several expressions and choosing a "best" match is going to make configuration very complex and cause unexpected interactions. For example changing a command resulting in some slightly different output may cause unexpected changes in the "best" match giving wrong parses and confusion about where it is happening.
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.
An inflexible matching with "slightly" different output will give you the expected beaviour: worse parsing, or none at all.
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 User independent commands regex ::= project, fallback geany.conf
Just use build_get_regex().
For compile, that's exactly what I'm going to do.
Using a regex that is hidden from the UI or is not associated with the command is bound to cause confusion.
Currently msgwin_parse_compiler_error_line() attempts filetypes_parse_error_message(), which uses build_get_regex(), *and* then falls back to parse_compiler_error_line().
So in "On compile", I'm reproducing the present logic, extended with best match. The latter really seems like an overkill for a single file, and I'll remove it.
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.
And always make the proper changes for a slightly different output. 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.
(?U) makes all matches non-greedy.
(?option) affects the text to the end of the current subpattern, or to the entire pattern if specified outside a subpattern.
It may be better to set ungreedy by default, (?-U) is still available, but I didn't want to modify the default POSIX-compatible behaviour.
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".