Hi Dimitar,
I'm afraid I am still confused by a few of your answers.
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. :)
Bet we get bug reports that users can't click on it :-)
- 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.
Thats easy to avoid, don't do it :)
An inflexible matching with "slightly" different output will give you the expected beaviour: worse parsing, or none at all.
1. and the fact that it isn't right will be visible to the user, black error messages 2. then they will know where to look to fix it instead of wondering which regex might be being used 3. trying a set of random regexes from different languages and sources isn't the way to go. a. you don't know which one it is going to use, remember these are user settings, they may not obey your listed rules for good regexes. b. there is a performance hit testing multiple regexes
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).
User independent commands regex ::= project, fallback geany.conf
Do you mean project filetype independent setting, user geany.conf filetype independent setting, system geany.conf independent setting (currently blank)?
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().
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.
If the user has set the regex to specify what is wanted as an error, they don't want Geany then second guessing them as well, and adding extra errors that are wrong. If they havn't specified a regex then a default fallback is ok.
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.
Agree, since filetype commands are, well, filetype specific, its best not to confuse 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.
users, you just can't trust 'em :-)
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. Warn in a different colour is worthwhile, anon and copy are, as you say, extras which wouldn't take much to add after named captures are added.
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.
(?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.
Yes, I was just adding other options to what I thought was your prototype documentation.
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.
Yes, it is best to leave it with the standard behavior, then it will work for those who don't read the manual (90%).
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.
Cheers Lex
[1] http://www.urbandictionary.com/define.php?term=super+dooper