problem reporter

[Daniel Franke]

Hi Sascha :)

> I wasn't aware of 4 problem reporters, too. Silly issue; probably we should
> adress that.

> > What does a problem reporter do? 
> >  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
> 6) jump to the requested location in source as the user asks for it
Since Messages and Find-In-Files (maybe others) already have a 
jump-to-line-at-file-functionality, I guess that this is a globally available 
functionality (something as "KDevXYZ::showLineAtFile(file, line)" )? 

> 7) maybe export to html ( or at least copy problems to clipboard )
Copy shouldn't be that difficult, export to html could implicitly done by 
doxygen? 

> These "todo", "bug", "fixme" and such are just additional features - but
> i'm pretty sure you already know that. :-) The "problem reporter" is
> misused in this case as something like a "grep" on all the sources...
> though, as the parser must walk the sources anyway, it can do that, too.
To be honest, I like that "additional feature" even more than the intended 
one ;) - to see whether my code has (syntax) errors, I just press [F8]. In 
general, I use the problem reporter (in sense of syntax problems) to see 
whether I forgot any '}' or ';'. I prefer using it as a reminder, that 
"There's some more work to do".

Regarding this, another issue: currently the problem-reporter reports problem 
of open files -all open files- including text/plain mimetypes as TODO or 
README. On the other hand, issues (fixme/todo) of closed files are not 
listed. I would like to see all my issues _without_ opening all files first. 
Also, the background parser reports dozens of errors in opened text/plain 
files - why does the backgroundparser have a look at them at all?

> >  * How to seed the new keywords to the parser/lexer? 
> Well, i suppose this has to be stored in the project DOM.
You are talking about the 'class DomUtil', aren't you?
I scanned the lexer as well as the parser, currently it doesn't access the DOM 
(by DomUtil). Querying the DOM for each file, at each commented line might 
decrease its performance significantly?! 

> > The cpp-parser was hand written, ad, java and pascal are 
> > antlr-based. Therefore there isn't  much of a unified interface.
> No, there is no unique interface. It has to be designed.
Can this be done without suffering a nervous breakdown? ;)

> > 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.
> yeah, you are kind of right on this topic. though, i do not really know how
> the starting- and ending- points of comment sequences should be known
> without a parser?
Ups, ok. Given a generic parser/lexer interface. It may define a virtual 
parse-method that, in its default implementation, reads the file and compares 
the character read with a start-of-comment character. if they match, another 
method is called that does the pattern matching:

--
class GenericParser {
	// QString instead of char to handle multi-char start/end sequences
	virtual const QString& startOfComment(void) const = 0;
	virtual const QString& endOfComment(void) const = 0;

	virtual void parse(...) {
		if ( currentChar()  == startOfComment() ) {
			readLineComment()
		} else
			nextChar();
	}

	void readLineComment(void) {
		// report any issues (@bug, @fixme, ...) found in range 
		// [ currentChar(), { endOfComment(), end-of-line } ]

		//
		// OR (even better - since it also solves the problem of
		// "how to get the keywords")
		//
		> When parser finds a comment it should emit a signal, giving filename,
		> startingpoint, endingpoint (and posibly comment in plaintext ) as
		> parameters. Then a slot inside the problem reporter could be connected to
		> that signal and parse it's additional keywords. OTOH, this way we could
		> keep doxygen syntax parsing away from the language parsers...
	}
};

class BashParser : public GenericParser {
	const QString& startOfComment() const { return "#'" }
	const QString& endOfComment() const { return QString::null; }
};
--
Most likely not exactly like this, but something similar maybe?

> > 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?)
> yes it is - and most likely it should be done. 
I already got my a pane of my own in the bottom dock, let's see ... :)

Regards
	Daniel
-- 
Dipl.-Math. (FH) Daniel Franke
Institut fuer Medizinische Biometrie und Statistik
Medizinische Universität zu Luebeck
Ratzeburger Allee 160, Haus 4
23538 Luebeck
Telefon: 0451-500-2786
Telefax: 0451-500-2999
daniel.franke at imbs.uni-luebeck.de