[Geany-devel] New messages/output parsing proposition

[Lex Trotman]

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 :-)

>
>> > 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.


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