After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 392640 - incorrectly placed curved lines between text panes
incorrectly placed curved lines between text panes
Status: RESOLVED FIXED
Product: meld
Classification: Other
Component: general
1.1.x
Other All
: Normal trivial
: ---
Assigned To: Stephen Kennedy
Stephen Kennedy
Depends on:
Blocks:
 
 
Reported: 2007-01-04 07:26 UTC by John Pye
Modified: 2013-07-03 16:50 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
(partial) screenshot showing the visual glitch (27.12 KB, image/png)
2007-01-04 07:27 UTC, John Pye
  Details
left-hand file (1.34 KB, text/plain)
2007-01-09 00:02 UTC, John Pye
  Details
right-hand file (1.37 KB, text/plain)
2007-01-09 00:03 UTC, John Pye
  Details
Another screenshot of the bug (18.03 KB, image/png)
2008-07-25 22:53 UTC, THEBAULT Damien
  Details
proposed fix: only ignore fully blank changes (5.31 KB, patch)
2008-08-03 17:49 UTC, Martin Renold
none Details | Review
proposed fix: only ignore fully blank changes (updated) (5.25 KB, patch)
2008-09-26 07:22 UTC, Martin Renold
none Details | Review
proposed fix: only ignore fully blank changes (updated again) (4.99 KB, patch)
2009-02-28 08:03 UTC, Martin Renold
none Details | Review
screenshot before/after this patch (48.96 KB, image/png)
2009-02-28 08:07 UTC, Martin Renold
  Details

Description John Pye 2007-01-04 07:26:08 UTC
Please describe the problem:
This is a GUI glitch in Meld that I've seen for certain cases. Looks like it might be something to do with where Meld considered a change to start and stop, perhaps something to do with blank lines.

Steps to reproduce:
See attachment screenshot

Actual results:
See attached

Expected results:
The curved lines should extend on the right to the top and bottom of the highlighted region of text.

Does this happen every time?
yes

Other information:
image will be attached after report submitted
Comment 1 John Pye 2007-01-04 07:27:59 UTC
Created attachment 79366 [details]
(partial) screenshot showing the visual glitch
Comment 2 Stephen Kennedy 2007-01-08 19:35:43 UTC
I think this is related to the "ignore blank lines" option.
Can you attach the relevant portions of the files and the status
of that option? Thanks.
Comment 3 John Pye 2007-01-09 00:02:52 UTC
Created attachment 79797 [details]
left-hand file
Comment 4 John Pye 2007-01-09 00:03:47 UTC
Created attachment 79798 [details]
right-hand file
Comment 5 John Pye 2007-01-09 00:04:58 UTC
I have the 'ignore blank lines' box ticked. Above attachments will reproduce the glitch.

Not sure if it makes any difference: I'm using "meld ." to do a svn diff.

Cheers
JP
Comment 6 THEBAULT Damien 2008-07-25 22:53:17 UTC
Created attachment 115276 [details]
Another screenshot of the bug

I have this problem too.

I think this is only happening whith blank lines before the text.

For example, with this very simple file:
> --1
> 
> a
> --2

and this one:
> --1
> --2

(This is the svn version (rev 1030), on gentoo linux)
Comment 7 Martin Renold 2008-08-03 17:05:03 UTC
It looks to me like the intention was to fully ignore the blank lines, meaning that they should not be not colored and the arrow buttons should not copy them. Note that ignoring blank lines is enabled by default.

This is annoying in the common situation where a change inserts a blank lines plus some new lines. You usually want to revert or copy the whole change, including the blank line. Right now you have to add or remove it manually after pressing the arrow button.

I still don't fully understand why trimming blank lines should be desireable. Related bugs are Bug #157873 and Bug #485253. I will attach a patch that changes the behaviour to only hide changes with nothing but blank lines.

Comment 8 Martin Renold 2008-08-03 17:49:54 UTC
Created attachment 115782 [details] [review]
proposed fix: only ignore fully blank changes

Side-Effects: This includes (and replaces) my fix for Bug #505087 and also fixes two other minor bugs:

1. no longer jump to the last blank changes if blank changes are ignored
2. no longer jump over blank changes if they are not ignored

On a related note, _consume_blank_lines() had a bug that made it trim only
from the top, never from the bottom. The patch replaces this function.
Comment 9 Martin Renold 2008-09-26 07:22:19 UTC
Created attachment 119401 [details] [review]
proposed fix: only ignore fully blank changes (updated)

Patch updated to latest svn, resolving a conflict.
Comment 10 Martin Renold 2009-02-28 08:03:05 UTC
Created attachment 129709 [details] [review]
proposed fix: only ignore fully blank changes (updated again)

Patch updated to latest SVN, resloving a conflict with the scrollbar drawing code.
Comment 11 Martin Renold 2009-02-28 08:07:38 UTC
Created attachment 129710 [details]
screenshot before/after this patch

Appart from fixing the problem with "forgetting" to jump to pure insertion/deletion changes, here is a screenshot how meld looks before and after this patch.
Comment 12 Kai Willadsen 2009-02-28 14:56:47 UTC
So this patch works for me in so far as it fixes these bugs.

Speaking more generally, I suspect that the way that the 'Ignore blank lines' preference works means that it's never going to function quite as desired. As it stands, blank lines are only ignored *after* the diff has been calculated, which means that they have to be accounted for everywhere we do drawing, and it's very difficult to do trimming, or to get the cleaner comparison that would (hopefully) result from ignoring whitespace.

I think the only way to fix this properly is to improve Meld's text filtering so that we can have filters that change the number of lines in the diff, at which point 'Ignore blank lines' becomes just another text filter.
Comment 13 Kai Willadsen 2009-06-27 08:02:07 UTC
This problem has been fixed in the development version. The fix will be available in the next major software release. Thank you for your bug report.