problem reporter

[Daniel Franke]

>> > 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?
There is a slot connected to the execute() signal of a ListViewItem, the
functionality I was referring to is implemented by
partController()->editDocument()


>> > 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
>
> _______________________________________________
> Kdevelop-devel mailing list
> Kdevelop-devel at barney.cs.uni-potsdam.de
> http://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel
>