jim said:
>   I decline to attach any verbiage at all.
>   I tell you I wrote it and you can use it any way you like
>   -- at your own risk and amusement, obviously.

except that some of that "verbiage" was people asking
just how exactly your program differs from one that
they've been using all along.  don't you wanna tell 'em?

and as for me, perhaps you noticed i congratulated you
for programming a tool.  was that just "verbiage" to you?

in addition, i will analyze any new tool, to check how well
it performs the job for which it is intended. it's fine if you
don't want to discuss it, but such a review is not "verbiage".
it's necessary to take an objective look at our tools to see
if they do the job, how they can do it better, and so on...

you specifically said your tool helps in 3 areas:
1.  line-break recovery
2.  error-flagging
3.  versioning

you even said:
>   my new tool has several tricks
>   that haven’t been seen before

(if anything has been "verbiage" in this thread, it's that!)

so, at the end of this post, i'll begin to look at those 3 areas.


>   If you need to get more serious than that
>   contact me by email and we can talk about it.

imagine the d.p. people had told you to make your complaints
"via e-mail".  i'd venture a guess that you would laugh at that...

***


>   On Vim I type:
>   :/[{|}]/
>   Which highlights the edits and takes me to the next set of edits

but that selects both the options, and the surrounding characters.

that's not really what you want -- what _most_people_ would want.

and it involves typing.  either typing or a lot of delicate deleting.
both of which increase the probability that errors are introduced.


>   When you are versioning it is frequently not as simple as
>   “choose A” or “choose B” but often a mix of both that
>   you have to edit.

i'm sure i know the reality much better than you do, jim, because
i've actually _done_ this resolution job, for lots and lots of books.

but maybe rather than schooling me personally, you've said this
for the benefit of the lurkers who might not have thought about it
very much, if at all.  (and that's an entirely appropriate thing to do.)

but if we're going to enlighten them, let's do it properly, ok?

your word "frequently" is simply (but completely) out of place.

in the vast majority of cases (96%) where there is a difference
between the two versions, _one_ of the versions is _correct_...

there _are_ some cases where both are incorrect, meaning that
you need to do some editing, but such cases are relatively rare.

in the last book for which i did a comparison, gardner's text,
there were 159 differences.  there were only _3_ cases where
_both_ versions were incorrect.  so yes, it happens, but rarely.


>   And I like seeing each next to each other in context
>   to help figure out what the “correct” editing moves are.

oh yeah, the context is _crucial_.

but i'm not sure that your _display_ is the optimal one...
it takes a lot of visual parsing to figure out a diff like this:
>   no way. There { warn't | wam't } a window to it big enough

personally, i find this display _much_ easier to understand:
>   no way. There warn't a window to it big enough
>   no way. There wam't a window to it big enough
>   ================^^============================

(i hope the monospaced font came through.  if so,
you'll see the "^^" markers line up with the diff.)

and i believe most users would agree that this display is better.

but, you know, if some users like _your_ display better, _fine!_   :+)

oh, and one more note on "context".  sometimes it can fool you.
the choice that looks right might not be what was in the book...
that's why it's vitally important that your tool show you the scan.
otherwise, you're doing your edits blind...


>   PS: You criticize me for doing that which the creator of wdiff
>   said he would do if only he had the gumption.

you'll need to provide a little more information to be understood.


>   How do you use wdiff to recover lost linebreaks?

i don't use wdiff for that.  i wrote my own program.

i asked carlo to explain how _he_ does it, but he never answered.
i found it humorous he was willing to come out to challenge you,
but isn't willing to come out when he is challenged...

***

anyway, in order to "kick the tires" on your pgdiff program, jim,
i'll set up some files that we can compare.  (real books, real files,
and not of my own choosing, either, but from rfrank's test-site.)

i'll run the files when i next find myself around a p.c. machine...
or, if you feel like it, jim, you can run them and post your output.

once i have some real output to look at, i'll be able to do a much
more thorough review of this new tool.

while you're waiting for that, though, here's a screenshot of a
tool that i wrote that makes it easier to work with jim's output.

>   http://z-m-l.com/misc/jim-tool-addon-screenshot.png

basically, when it finds a line with a diff in it, it presents the
options to the user, who can then click a button to choose one,
or enter a number -- 1 or 2 -- to activate the appropriate button.

in the case where editing is needed, either option can be edited
before the button is clicked to select it.  the "stop loop" button
will stop the loop that presents the next diff display; otherwise,
the app loops through the entire file, jumping to the next diff.

so, you see jim, i'm really trying to _help_ you in your quest here.

-bowerbird