Re: [PATCH] new option --ignore-trailing-space-change for diff

[Paul Eggert]

Roland McGrath <address@hidden> writes:

> This patch adds --ignore-trailing-space-change, short option -z.  This is
> similar to -b, but ignores only trailing white space.

That sounds like a nice thing to add; thanks for the suggestion.
However, I'd prefer the name --ignore-trailing-space (without the
-change) as the option ignores all trailing spaces.  Also, perhaps
some day we'll want to add an option to ignore leading white space
too.  With that in mind, how about if we use the short name -Z, so
that the leading-white-space option could be called -A (-a is taken).

> I am not really sure about some of the tests done on
> ignore_white_space in analyze_hunk and find_and_hash_each_line,
> which do magically different things depending on < or >
> IGNORE_WHITE_SPACE.

Here's the basic idea.  Logically speaking:

  --ignore-all-space (-w) implies --ignore-space-change (-b).
  --ignore-all-space (-w) implies --ignore-tab-expansion (-E).
  --ignore-space-change (-b) implies --ignore-tab-expansion (-E).

and therefore all these options can be encoded as a single scalar
value, since they form a strictly increasing relationship.

> in fact -z could be orthogonal to -E and one might very well want to
> use both.

Yes.  Also, it is independent of -b.  We have:

  --ignore-all-space (-w) implies --ignore-trailing-space (-Z).

but we don't have any other new relationship.

One way to solve it would be to make room in the enum encoding for -Z
+ -b and -Z + -E.  That is, the enum encoding could really be
ORed-together bit fields, at least as far as -Z is concerned.

Another idea: the hashing and comparison functions should be adjusted
so that they make only one pass over a long run of spaces that is not
followed by a newline.  This can be done by computing a provisional
result that is carried along while we see whether the spaces are
followed by a newline.

> If there is anything I can change that will convince you to put this into
> diff, please let me know.

I like the basic idea.  Aside from the above, the most important
things you can do to make it easy for me is to get the paperwork
signed (you haven't signed paperwork for diffutils, sigh) and to be
write up the changes to usage(), diffutils.texi, NEWS, and ChangeLog
entries.  Also, sdiff needs a similar change.

If you don't have time to do all this, I'll volunteer to do it, as I
think the suggestion is a good one.