problem reporter

[Daniel Franke]

Hi all :)

I just played with configureable keywords to the problem reporter (@bug,
\issue, ...) when I realized that there is not only one problem reporter,
but there currently are FOUR (ada, cpp, java, pascal) - naivly I took cpp
for granted and hadn't had a look in the different directories before
hacking away :(

Giving the current language-support setup some more thougt:
Each language defines its own config-page (which is reasonable) and its
own problem reporter (which is not reasonable).
What does a problem reporter do? It displays five pieces of information:
 1. the type of the problem
 2. the file were the problem occured
 3. which line in previous file
 4. which column in mentioned file
 5. a description of the actual problem at hand

This should be true for any language: cpp, java, ruby, ...
So, is there really need to implement it N-times? (There might be, I
neither know all languages supported nor was I involved in development so
far - there are obviously reasons why it was done this way, but I don't
know them.)

I now spent quite a while with this and I found two major obstacles:
 * Either keywords are defined on a per-language base, or globally. In my
eyes language based keywords would lack any sense since a @todo is a
@todo, in ada, cpp, java, python, whatever. In addition, since they are
so similar, the same code is duplicated N-times instead of re-used
N-times. Therefore I conclude they should be defined globally ;)

 * How to seed the new keywords to the parser/lexer? That's more or less
the same question I asked a few days before (no one replied so far).
Shall a lexer access config files or not? Most likely it shall not. So
they have to be handed down from backgroundparser to driver to lexer ...
(more or less this way) - But where is the problem? The cpp-parser was
hand written, ad, java and pascal are antlr-based. Therefore there isn't
much of a unified interface.

The advantage of an unified interface: any language could be provided with
problem reporter functionality, even without a working parser, as long as
the start-of-comment-sequence is known, e.g. for bash, the parser/lexer
will skip anything, but '#', then (until end of line) the globally defined
keywords will be searched and found "problems" will be reported to the
(globally available) problem-reporter-part.

To those who know more about parsers and lexers: would it be possible to
create a global interface to hand-written and antlr-based parsers, that
might be used as a skeleton to implement a "keyword-only" problem reporter
easily (as described above)?

To those who have a deeper insight in part/plugin-handling: is it possible
to release the problemreporter from its language dependency and use it as
a part/plugin on its own? (Most likely it is _possible_, but is it also
reasonable to do so?)

Regards of an interested-user-who-still-doesn't-understand-
too-much-of-how-kdevelop-works