[darcs-users] DARCS changes XSLT stylesheet
Sean E. Russell
ser at germane-software.com
Wed Nov 19 15:24:34 UTC 2003
-----BEGIN PGP SIGNED MESSAGE-----
On Tuesday 18 November 2003 23:29, BARBOUR Timothy wrote:
> I don't think I am using the wrong tools. I use ediff or tkdiff, both of
> which provide extensively coloured displays, support merging etc.. The
> problem with all these tools is that, where a few characters have changed,
> one has to look from one version to the other and back, trying to line up
> the parts by eye. By contrast the strike-through approach presents both
KDiff3 colors not only the line that changed, but also colors differently the
*characters* in the line that have changed. For that matter, vimdiff does
the same thing.
You are right -- granularity is nice to have, which is basically what you're
talking about. You also don't like the format; you want to see the diffs
in-line, as it were.
There isn't a solution for turning diffs into the kind of in-line display that
you'd like to have, primarily because diff only notices line-level changes; a
diff doesn't have enough information to mark up character-level changes.
You'd need a more granular diffing algorithm.
> I would really like to be able to convert diff(1) output into HTML with
> strike-through. I have thought of writing a tool to do this, but could not
> muster the effort to parse the diff(1) output. I mistakenly thought that
> you were producing diffs in XML format already.
Diff output isn't difficult to parse, if you stick with one set of parameters;
interpreting it and merging it with existing source may be a bit more work,
because you'll be duplicating the patch tool.
> Based on the screenshots at http://kdiff3.sourceforge.net/doc/features.html
> , KDiff3 looks much the same as the other colourful diff utilities - no
> significant improvement.
It seems to me the only thing kdiff3 doesn't do that you want it to do is
display the changes inline. It does support character-level granularity (as
> From what I can see at http://www.hackorama.com/kompare , Kompare does not
> show individual differences at all.
No, but the UI is excellent for readability. My trouble with side-by-side
diffs is that it is often difficult to see what the code on each side is
*supposed* to be doing. Personally, I find inline diffs, like the
strike-through you mention, is even worse for reading code than the usual
diff displays. I agree that, for natural language, inline diffs are
preferable. This, I believe, is because we don't read code the same way we
read written text, and that the nature of the common change in the two is
In my experience with software development, blocks of code change, not just a
character here or there. Blocking out entire "paragraphs" of code inline
just makes following the flow of code impossible for me.
However, this is just a difference in taste. Your desire for inline diffs is
> I usually have a version-control tool to do merging for me, so I am mainly
> interested in reading diffs efficiently. When I do need to merge manually,
> emerge serves me well.
Ah. We have different use cases, then. Usually, the only time I'm reading
diffs is when I'm trying to resolve conflicts, where the version-control
software is no help. In that case, I'm trying to figure out what each bit of
code does, and which is more correct, and merge them. Actually, even when
I'm not resolving conflicts, I'd still rather be able to follow the flow of
the code in both cases.
If you're willing to spend $79, there is a tool (for Linux, BSD, Windows,
Mac...) called Guiffy:
that displays diffs both inline and side-by-side.
### http://www.germane-software.com/~ser jabber.com:ser ICQ:83578737
### GPG: http://www.germane-software.com/~ser/Security/ser_public.gpg
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
-----END PGP SIGNATURE-----
More information about the darcs-users