problem reporter

[Daniel Franke]

Hi Sascha,

>> > 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 the KListView. The
functionality I was referring to is implemented
by partController()->editDocument(url, line) :)

>> 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?
Nope, automake based projects. Add a new (blank) file to any project, type
some text. This adds any number of syntax errors to the problem reporter.


>> > >  * 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();
DomUtil::readEntry(*project()->projectDom(), "an/xpath") ?

> ProblemReporterFrontend and store the keywords in a QStringList. Accessing
> the QStringList is the least expensive way to do it, i think.
... and re-read the configuration whenever the settings have changed.
Agreed :)


To parse only the files (file/mime-types) that are supported by the
current language, I thought about adding

    const QStringList& KDevLanguageSupport::headerTypes(void) const;
    const QStringList& KDevLanguageSupport::sourceTypes(void) const;

where both of the lists should be user-configureable (mimeTypes() as
well). Given these members, it should be easy to implement the
part-added/changed/removed slots.
Maybe the (background-)parser should be accessable through
languageSupport() also, but I'm not yet sure about that ...

Cheers
    Daniel