[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