[darcs-users] DARCS changes XSLT stylesheet

Sean E. Russell ser at germane-software.com
Wed Nov 19 15:24:34 UTC 2003

Hash: SHA1

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 
does vim).

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

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

- -- 
### SER   
### Deutsch|Esperanto|Francaise|Linux|XML|Java|Ruby|Aikido|Dirigibles
### http://www.germane-software.com/~ser  jabber.com:ser  ICQ:83578737 
### GPG: http://www.germane-software.com/~ser/Security/ser_public.gpg
Version: GnuPG v1.2.1 (GNU/Linux)


More information about the darcs-users mailing list