Re: "static/fixed" mode on file diff view



On 7 March 2013 07:04, Pedro Pedruzzi <pedro pedruzzi gmail com> wrote:
On Fri, Mar 1, 2013 at 5:49 PM, Kai Willadsen <kai willadsen gmail com> wrote:
On 26 February 2013 06:58, Pedro Pedruzzi <pedro pedruzzi gmail com> wrote:
Thanks for the pointers.

I've came up with this proof-of-concept based on the second option.
The tags isn't getting updated on buffer change yet. This is just to
demonstrate how would it look and feel.

Please, tell me what you think.

I'm actually surprised how well that works! I think we need to figure
out a way of doing what other diff tools do, and indicating the areas
that have been inserted to get the alignment right. I'm not sure
whether GtkTextView will let us do that easily, but we can see.

I've just had an alternative crazy idea. If tags don't give us the
flexibility we need, we could always insert a custom GTK widget after
each chunk, and give allocation to the widget based on required
padding. That should allow us to use whatever presentation we like.

...don't do that though. That's a crazy idea.

I have some questions:

1. Where is a good place to do the tag creation? I tried somewhere in
the constructor but it seems that the linediffer was not ready to
iterate over changes yet.

I can't see any way of getting away from having a tag per chunk, which
means that there's no way to do it in the constructor. You can do this
is many places, but FileDiff._diff_files() is the first place where
we're guaranteed to have the diffs. Of course, those diffs can change,
and if they do then we'll get a callback to
FileDiff.on_diffs_changed(), which would probably be the right place
to update and revalidate tags.

2. How about 3 way filediffs? I would need to iterate over chunks on
the 3 panes.

Exactly. Things are always complicated by 3-way diffs, but in this
case I think it's just a matter of adapting your code to use
linediffer.all_changes() instead of single_changes() and taking the
max of three offsets rather than of two.

cheers,
Kai


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]