Kompare support for patch and difference reviewing

[Aleix Pol]

On Thu, Aug 6, 2009 at 8:43 AM, David Nolden <
david.nolden.kdevelop at art-master.de> wrote:

> 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?
>
 We're working on an IDE, we want something integrated. It would be good
but... we can do better.


>
> 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.
>
Plus we don't maintain it.


>
> 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.
>
I don't think it would be inconsistent, even if the semantic stuff is
useful, it's just fine to read the code when reviewing.


>
> Greetings, David
>
>
> _______________________________________________
> KDevelop-devel mailing list
> KDevelop-devel at kdevelop.org
> https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel
>

So are you planning to get this to work? if you do I won't keep working on
that, I don't want 2 conflicting patches. I can let you work on that if you
wish, and we see what happens.

Thanks,
Aleix
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20090806/d647ec2b/attachment.html>