Patch: TODO highlighting in comments

[Dmitry Risenberg]

Got some new features in Problem Reporter:

1. Selecting scope of displayed errors: you can now choose between
displaying errors from current document only, from all open documents,
from documents in a current project or from documents in all open
projects.
2. Enabling/disabling showing problems from imported (included in case
of C++) files. By default errors in imported files are not shown.
3. Selecting severity of displayed errors: only display errors with
given severity or higher (Hint < Warning < Error).
4. Switching autoresizing columns when errors are added into the
widget on/off, so that long error descriptions won't make the last
columns run past the screen end.

I'm not sure whether "Force Full Update" action is worth keeping and
what its semantics should be. As for now, I made it re-parse all
documents in current scope (see \1), and do it recursively if problems
from imported files are to be shown. Re-parsing everything is rather
slow when there are many documents in scope, especially with imports.
I'm not sure if there are valid use cases for this action, except a
case when some files change that are external to the project/session,
for example a library is updated, but this isn't a common one. Another
possibility could be providing on-demand parsing when the user
switches off on-line parsing, but AFAIK now there is only an option to
switch the parser off completely.

Here's the code (not making merge requests because there's still work to do):
http://gitorious.org/~dmitryrisenberg/kdevelop/dmitryrisenberg-kdevplatform/commits/todos
http://gitorious.org/kdevelop/dmitryrisenberg-kdevelop

What's on the plans:
- Make the list of "todo" words configurable.
- Save user settings for scope, severity, etc. between sessions.
- Filtering errors by component (parser, preprocessor) - this doesn't
seem necessary as long as there is filtering by severity.

Suggestions on other features and feedback are welcome.

Dmitry Risenberg

2010/10/17 Andreas Pakulat <apaku at gmx.de>:
> On 17.10.10 02:43:14, Ciprian Ciubotariu wrote:
>> Though perhaps a bit off-topic, I'd like to use the opportunity to add some
>> thoughts on having configuration levels and a system for overriding these as
>> the scope tightens. I've mentioned this idea on IRC (I am CMoH on IRC btw) but
>> didn't raise any comments.
>>
>> Here is what I'd expect from the IDE's configuration framework:
>>
>> 1. application-level configuration
>> 2. session-level configuration
>> 3. project-level configuration
>> 4. perhaps file level, but I've seldom used such a feature except in those
>> nasty IDEs that also handle the build themselves
>
> Actually it should be app-level < session-level < project-level <
> developer-level. The last one is whats stored inside
> <project/.kdev4/<project>.kdev4. The project stuff is in the
> top-level <project>.kdev4. File-level is totally useless except for a
> very few things and for those rare cases having a way of just writing a
> special config file somewhere should be enough.
>
>> Each level is the default for the higher levels, where level 1 (application
>> level) would define a value for all options. Each level above would allow me to
>> override the values supplied by the previous level, or to reset my change.
>>
>> There's also the question on where to store transient configs, like session
>> open windows, current window layout, currently selected filter in the TODO
>> window and similar stuff.
>>
>> Would you find idea this useful? Does it stand any chance within the current
>> KCM design (I haven't even saw its API)?
>
> We actually had a start of that about 2-3 years back. It was quite a
> hack and had no suitable GUI either. So basically this merely depends on
> writing a suitable GUI to move options up/down and someone finding a
> suitable way of implementing this with KConfig or write a KConfig
> replacement which does support what we need. The project-kcm's and the
> IProject::projectConfiguration() does some cascading already, but
> especially the kcm-config-setup with The ProjectKCModule and
> ProjectConfigSkeleton is quite cumbersome and error-prone.
>
> Andreas
>
> --
> Good day to let down old friends who need help.
>
> --
> KDevelop-devel mailing list
> KDevelop-devel at kdevelop.org
> https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel
>