Kompare support for patch and difference reviewing

David Nolden david.nolden.kdevelop at art-master.de
Thu Aug 6 06:43:48 UTC 2009


Am Mittwoch 05 August 2009 22:03:13 schrieb Andreas Pakulat:
> > By annotated in this case, I mean having highlighted all changed hunks in
> > the code, and allowing to jump between, edit them directly, and reverting
> > them with a click. Essentially the same thing you can do with kompare,
> > except that we would have code-highlighting, -editing, and all the bling.
>
> Ideally yes, but that'll take some serious amount of work and time.
>
> > Most of the required code is already in the teamwork plugin,
>
> Yeah, unmaintained for more than a year now, no thanks I think.
> Especially since that would mean having to extract it from there, check
> wether the difflib still is up-to-date, having a conflicting library
> with kompare etc... I'd rather have kompare extended to allow in-place
> editing if you ask me. That one is at least properly maintained and we
> don't have to do all the dirty work ourselves.
I've already extracted it here locally, and I'm building a toolview out of it 
that can take an arbitrary _applied_ patch, highlight it in the code, and 
allow jumping between it.

It should be ready in a few days in a nice state if I find time for it again. 
It isn't much work.

Given all the problems you guys are facing with embedding kompare, the 
question arises, why do we even want to _embed_ kompare? Wouldn't it be 
perfectly ok to by default highlight the changed code directly within kate 
text editors using that toolview, and having a button in that toolview to 
launch kompare in a separate window on the diff?

As the main advantage I see in kompare is that it can outline the changes in a 
compact way, that way we would have a logical split of functionality.

As to improving kompare: Even if the patch was fully editable within it, we 
still wouldn't have semantic- and syntax-highlighting there, and also no code 
completion. So, especially if the kompare part was embedded, this would lead 
to an inconsistent editing experience.

Greetings, David





More information about the KDevelop-devel mailing list