problem reporter

[Sascha Cunz]

Hi Daniel,
> > 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)"
> )?
Doesn't any Problem-Reporter implementation have that too, yet?

> > 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?
HTML export isn't that important. can as well be achived in doxygen. So i 
totally agree on that point.

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

Actually, that's what doxygen is for. Sure, most of the time i'd like to see 
"what's to do" in a short and quick way.

> 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?
This sounds like a bug. Do you happen to be using a "custommakefile"-based 
project?

> > >  * 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?

to be exact, it is the return form KDevApi::projectDom();

> 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?!

Given the fact, that we create a "comment-parser" like in my proposal, i don't 
see any cause not to read the project dom while loading the 
ProblemReporterFrontend and store the keywords in a QStringList. Accessing 
the QStringList is the least expensive way to do it, i think.

> > > 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? ;)

We had a talk about that in chat. I think it can be solved easily.

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

Yepp, but at this point we're back to a generic language support. I think it's 
not a bad idea to have a such a think. And the code above looks like it could 
be actually a base for that.

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

:-)

Cheers Sascha