Re: Adding an "Ignore trailing spaces" text filter

[Kai Willadsen <kai willadsen gmail com>]

On 22 January 2013 03:45, Angel Ezquerra <angel ezquerra gmail com> wrote:
> Hi,
>
> it would be nice if meld came with a built-in "Ignore trailing spaces"
> text filter, such as:
>
> [ \t\r\f\v]*$
>
> This would nicely complement the existing "All whitespace" and
> "Leading whitespace".
>
> I often need to do this because some editors automatically remove
> trailing spaces which often creates spurious differences.

I don't disagree, but our filter list is really meant as a base for
people to customise, rather than as a comprehensive list of filters
you might need. Part of that is because of the limited nature of the
filtering, as you mention below.

> Also, it would be cool if you could specify a "replacement" string
> with your text filter expressions. Currently the implicit replacement
> string is an empty string. This is often what you want but it does not
> let you do things such as creating an "ignore white space changes"
> text filter such as the ones that are provided with mercurial diff.
> The way this works is that all white space "blocks" (i.e. contiguous
> strings of white spaces and tabs) are replaced by a single space
> before the comparison is run. This means if the amount of whitespaces
> between words changes the diff tool ill ignore it.
>
> Another thing that could be done with this sort of "advanced filter"
> would be to compare files that have different indent options (e.g. one
> indents with tabs and the other with spaces), by replacing [\t]{1}
> with " ".

The existing 'leading whitespace' filter will get you most of that as
it stands, with the only difference being that there's no way to pick
out significant whitespace.

The problem with replacing text is that it breaks user expectation
when people discover that text filters *don't* apply to Meld's inline
highlighting, only to large-scale differences. They *should* apply to
the inline highlighting, but doing so requires keeping a reverse
mapping from the transformed text to the visible text so that we can
correctly apply the highlight, and no one has written that yet.

In the end, we actually need a significantly more sophisticated filter
mechanism to fix these problems (including the long-standing line
break limitation) and I just don't have the time. If anyone is keen on
working on it, then I'm happy to give some pointers, but it's not
likely to be a quick fix.

cheers,
Kai