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

[Roland McGrath]

> 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 don't care what the names are at all, as long as there is a short option.

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

I understand that.  It's really just this bit:

    if (ignore_white_space < IGNORE_SPACE_CHANGE)
        bucket = &buckets[-1];

that I don't really understand the meaning of.

> Yes.  Also, it is independent of -b.  

No, it is a subset of -b.  Any difference that -Z ignores, -b ignores too.
What case am I missing?

> 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.

Certainly worthwhile.  I just did the implementation that was
straightforward and worked, realizing it is not optimal.  But it's what I
did on a brief tangent last night in the middle of composing the email
submitting a patch elsewhere, when I suddenly decided not to just hand-edit
out the whitespace.el-induced hunks from a diff without -b after a -b diff
elided a necessary indentation change, like I have done a zillion times
before.

> 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) 

Oy.  I suspect the FSF trusts me to follow up on papers and you don't
really need to wait for all the snail mail exchanges before using my code.
I don't appear in copyright.list for diffutils, but the ChangeLog shows I
have ever contributed to it.  In fact, it looks like I made the 2.2
release!  (Who knew?  Not me.)  That was all while I was an FSF employee,
though we employees did all file individual copyright assignments for
things at that time.  Last night I dithered for a moment about whether to
use my personal or work email address for that submission.  How about if I
say it was part of my job at Red Hat?  Submitting the other patches that I
added -z so I could make more easily is certainly part of my job there, and
my job description is rather fungible that way.  Then it would be covered
by the company's blanket assignment.

Anyway, if you make all the changes you've mentioned, you will have
rewritten it all from scratch.

> and to be write up the changes to usage(), diffutils.texi, NEWS, and
> ChangeLog entries.  Also, sdiff needs a similar change.

My patch does include ChangeLog entries for what I wrote, and does update
the usage message.  I know not from sdiff, but it looks like it just needs
to know a new option letter to pass along to diff.  

> 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.

I certainly have more than enough other things to do, and what I've written
is working great for me now.  I'm sure being able to do -tZ instead of my
current -z behavior would be ideal for my uses, but I'm not that likely to
actually be bitten by the inability to use -T with it in practice.  So if
you are willing to polish it all up and put it into diff yourself, then I
would certainly appreciate that.



Thanks,
Roland