Re: Much easier way to do file comparison

["Robert Holmgren" holmgren@xxxxxxxx]

** Reply to message from Harry Binswanger  on Sun, 06 Nov 2005
16:23:58 -0500


> The result, unfortunately, for my two files is a mass
> of red and green text,--after a point where they get sort of out of
> sync--with only a little unaffected text.

*All* files get out of sync if there are massive differences and the FindMatch
algorithm can't find any matches anymore (it gets confused -- happens very
often -- surely you know that, and have experienced that). You may not see the
errors *at all* if you're only looking at one side of the equation -- at just
one of the two files. Even when they're waaaay out of sync, func FM FindMatch
does its best to try to get back into sync somewhere/anywhere -- and indeed it
may, but with tons of intervening errors. You can't ask of XyWrite what it
can't produce. Try it with only minor differences between the two files, a few
words or sentences here and there. It works perfectly well -- after all, it's
your procedure that I'm using, without change!

> Your program is the solution for one-iteration comparisons.

Actually, I agree with Carl: FINDDIFF is better -- better than a two-iteration
implementation, and more useful than this. But for a
*single-window/single-file* implementation, where you don't have to look
back-and-forth, this does work. The problem is getting rid of the  and
 commands, and possibly the text that they enclose. If I was doing this
myself, in place of your direct MD colors I'd use actual Redlining 
commands -- then you could delete the text which is currently red with a simple
PE command, whilst also wiping out the mode commands that create green (but not
delete the green text itself). You can make the pertinent Redlining modes be
any colors you want (e.g. red and green) with simple entries in the DFL file.
If you want, I'll implement that -- that would approach the efficiency of
FINDDIFF. But FINDDIFF has a big advantage, IMO: the main reason most people
compare is to make actual edits, and FINDDIFF does that directly. No complex
cosmetics to cleanse, no clutter, no horsing around.

> I hope it didn't take you too long to write it.

Very little. What takes time is the commenting, with clarity. How much do you
have to explain, what level do you pitch the explanation at? Finding that
balance takes forever. I write the code in my head first. I have rolls of
toilet paper with my resumé printed on each sheet; the sight encourages me to
daydream instead of drum up work. In truth, there's nothing new or remarkable
here. U2 has so many facilities that make writing/checking/simplifying code
easy.

-----------------------------
Robert Holmgren
holmgren@xxxxxxxx
-----------------------------