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

[Kai Willadsen <kai willadsen gmail com>]

On 26 February 2013 06:58, Pedro Pedruzzi <pedro pedruzzi gmail com> wrote:
> Hello, everyone!
>
> I'm a happy meld user and I've just joined this list because I have
> some improvement ideas I'd like to share, discuss and help implement.
>
> The current visual highlighting of matching chunks is awesome. But the
> scrolling can get a little confusing to use because it lacks
> one-to-one alignment between lines in the panes.
>
> I'd like to experiment adding an option to make the diff view
> scrolling fixed between panes. I'd have to add vertical spacing in the
> panes to fill the gaps (can be done with "null" lines), so that
> identical lines are always aligned (regardless of the scrolling
> position) and so are matching chunks.
>
> What do you guys think of this idea?

Plenty of people have requested this before, and I'm pretty sure
there's a bug somewhere. It would be nice to have, but it's not all
that easy to add.

> I'd appreciate some guidance on how this could be hacked in the code base.

It will be difficult to know what the best approach is until you're
half way through. There are two basic options that come to mind: add
extra linebreaks into the buffer, but make sure to account for them
whenever handling text; or try to get the textview to do the extra
padding for you. Both are probably broken in different ways (e.g.,
line wrapping).

For the first option, Meld has a strong assumption that the textbuffer
isn't going to lie to us about line numbers. We assume that line 7 in
our comparison will be line 7 in the buffer and vice versa. Fixing
this would be a big undertaking, and would have all sorts of edge
cases, but if done properly would be very worthwhile.

The second option is to get the gtk.TextView to artificially inflate
the last line of each misaligned chunk. This *should* be significantly
easier, but not trivial to do properly. Basically, you'd create a tag
per chunk and per pane, and iterate over chunks, checking to see
whether their ending text iters y-locations match. If not, adjust the
relevant tag's pixels-below-lines & pixels-below-lines-set properties
to make them match. The hard part comes when the buffer changes and
the tags need to be cleaned, adjusted, revalidated, etc. As a
proof-of-concept, the first part could be done in
FileDiff.on_textview_expose() I think, but in the long term I think
doing the tag manipulation in there would be too slow. I haven't tried
this, but I think it should work.

Anyway, it would be cool to have this option, so if you have any
questions, feel free to ask.

cheers,
Kai