[Geany-devel] New messages/output parsing proposition

[Dimitar Zhekov]

On Mon, 29 Aug 2011 11:16:05 +1000
Lex Trotman <elextr at gmail.com> wrote:

> >> Whats anon for? [...]
> >
> > To have it colored as error or warning. A bit of FX. :)
> 
> Bet we get bug reports that users can't click on it :-)

I can trust them that much... :)

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

Yes, it can be easily avoided by by writing the expressions to require
one of the known extensions for the file type, and classifying the
filename-line-column match as "Good". So the "Best" becomes absolute.

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

The home filetype or the system filetype file.

What is the "default (is currently blank)"?.. I searched Geany for
global fallback expression(s) short time ago, but all I could find
was 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.

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

I imagine myself navigating thru the build dialog, copy-pasting all
filetype expressions that can be relevant to the project, for every
project. And then changing all of them on each slightly different
outout... And then I'll finally sit back and say: "There is nobody
to blameth, cause I brouth this on myself". :)

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

With enough | expressions, anything will work. I'll can very long, but
a regex limit is 64K...

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

You saved me even more work. With a single regex defined in 54 system
filetypes, and 4 mentions of the message parsing in 1320 tracker items,
It odesn't look like anybody needs a new parser, much less anyone is
going to define complex new-style regex-es.

So I'd better head to more practical things: column support and
optional underlining for the Messages tab, and optional mark all Find
Usage matches.

BTW, how about closing 3039654, and writing some comment for 3156609?

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

In the Message Window, the "Messages" tab on the left. It's parsing is
completely different from the "Compiler" tab.

-- 
E-gards: Jimmy