Re: Bug in directory view

[Kai Willadsen <kai willadsen gmail com>]

On 16 March 2013 00:32, Jeff Webb <jeff webb nta-inc net> wrote:
> On 03/14/2013 04:20 PM, Kai Willadsen wrote:
> > That also won't work for unicode or mac linebreaks, so we'd need to
> > establish a list of linebreaks that would be ignored in FileDiff by
> > the preference (which will then break when GTK or Python changes their
> > definitions, but hey).
>
> That sounds like a good solution to me.  I was also worried that the patch I
> posted may slow things down for large directory diffs, since it is an extra
> step to run on each file.  Perhaps being able to enable this feature in the
> dirdiff "Filters" drop-down would be a good idea, if that is an issue.

Of the many very-slow things that we do in directory comparisons, that
one shouldn't be a real problem. It is, essentially, just applying
another filter if the option is set.

> > I'd like to fix the bug, but I don't want to encourage the idea that
> > that should work. I have to admit that it never occurred to me that
> > the blank line ignoring *would* propagate across to folder
> > comparisons. Basically, it's only there cause our filters can't handle
> > new lines.
>
>
> My use case really has to do with the text filters as well, so I think the
> bug is legitimate in that context.  As you mentioned, if the filters could
> handle new lines, this feature wouldn't matter very much. In my case, I
> want to see only non-comment differences between two revisions of a source
> tree.  Someone decided that putting a revision number (and change log) in
> every file was a good idea, so it looks like every file has changed between
> the two revisions.  With my patch applied, I can see which files have
> significant changes without having to examine every one individually.  When
> I examined the meld source code, I discovered that the underlying issue was
> that even though the text filters were applied, the line differences
> elimination code was not.  That's why I described the bug the way I did.  I
> thought it would be more clear to not mention the text filters, since that
> part seems to be working properly.

Sure. The problem from my point of view is that the ignore-blank-lines
setting is intended as a visual aid in file comparisons, and here it's
being repurposed. I certainly think the use case is reasonable; I just
wish that we weren't using the ignore-blank-lines setting for it. I
can live with it for now though.

> > Could I ask you to file a bug please, and I'll take a look at a more
> > general patch?
>
>
> Sure.  I just filed Bug 695912:
>
> https://bugzilla.gnome.org/show_bug.cgi?id=695912
>
> Thanks for taking the time to examine this issue.  Also, thank you for your
> work on meld.  My coworkers and I find the tool very useful.  I also love
> that it's written in python -- that made it easy to dive in and fix the
> issue.

Thanks! Always nice to hear that people find it useful.

cheers,
Kai