[Geany-devel] New messages/output parsing proposition
elextr at xxxxx
Mon Aug 29 23:59:13 UTC 2011
>> 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.
Good point, the expression could handle multiple extensions too, eg
makes it deterministic.
> 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().
Sorry, build_get_regex() used to also look at default, but I forgot it
> 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". :)
Indeed, but its better that shouting, "Where the [long string of
expletives deleted] is it getting that from ..." :-)
> With enough | expressions, anything will work. I'll can very long, but
> a regex limit is 64K...
Just how many languages do you mix? You only need the ones you use in
the project. Most sane people tend to limit themselves to only a few,
one or two code plus one or two documentation. Like Geany does. People
who don't limit themselves become insane :-D
>> 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
>> 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.
Good analysis, as I said in the past, there is only a single filetype
regex because the hard coded method came first and no-one has had time
to change anything. Its not because they think the current system is
Of course we don't know how many user defined regexes are out there
working perfectly and silently.
> 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.
Well, using named captures and so allowing multi-language regexes is a
useful improvement. Having to select a C++ file before building is
annoying (Python only throws one error at a time so its better to get
the C++ errors parsed). The named captures also helps your column
support be more robust.
> BTW, how about closing 3039654, and writing some comment for 3156609?
Sure, I'm currently behind a corporate firewall which doesn't let me
login to sourceforge (or the wiki) and looks like being another couple
of weeks before I'm finished. So if someone else wants to close the
first and note on the second that the documentation already says new
entries override old ones, see
http://www.geany.org/manual/current/index.html#old-settings then it
won't be forgotten, thanks.
> In the Message Window, the "Messages" tab on the left. It's parsing is
> completely different from the "Compiler" tab.
Ahhh, I had forgotten that the messages window parsed anything.
More information about the Devel