[Geany-devel] New messages/output parsing proposition
Dimitar Zhekov
dimitar.zhekov at xxxxx
Sun Aug 28 18:44:52 UTC 2011
On Sun, 28 Aug 2011 15:32:19 +1000
Lex Trotman <elextr at 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. :)
> > 2. 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".
--
E-gards: Jimmy
More information about the Devel
mailing list