Perhaps someone has the time to inject this thread into the Wiki?  ;-)

On Thu, Jun 29, 2006 at 12:14:12AM -0700, Jimmy Huang wrote:
> Thank you for being so thorough and detailed. 

Normally people tell me I think too much.  ;-)

> I really appreciate the pointer on emacs! This will
> help me alot. 

There are plenty of other ways to do similar things in emacs, do a
search for "tabs" in the Emacs Wiki.  You may find other useful tricks.

Another trick that I use is to use "darcs diff -u > darcs.diff" and then
open darcs.diff in Emacs.  This opens it in diff mode, and you can step
through each change, visiting the exact line of each source file

You can also select "Apply diff with Ediff" (A) ... Ediff is fantastic,
shows you more detail about a change than just the diff.  It's worth
learning how to use.

> So I guess darcs treats tabs/spaces different on purpose so it looks
> non-lined up when the "style" changes! 

No, not really.  Or rather your explanation is insufficient.  Darcs is
merely observing changes to the bytes in the source file.  A source file
is a stream of bytes.  

It is our use of tabs in the file that creates the issue.  If we did not
use tabs, there would be no problem.  But we have to use tabs because
some of the files already use tabs.

Also, you might not be understanding what causes things to look
different ... so I shall try to explain.

Imagine a line consisting of a tab followed by an asterisk.  The
following line below contains only that:


A file containing this can be created on UNIX systems by typing a

$ echo -e "\t*" > file

Using the od(1) command in Linux, you can see various ways in which this
stream of bytes appears:

1.  in hexadecimal bytes, the 09 is the tab, the 2a is the asterisk, and
the 0a is the newline:

$ od -t x1 file
0000000 09 2a 0a

2.  in ASCII characters or backslash escapes, the \t is the tab, the *
is the asterisk, and the \n is the newline:

$ od -c file
0000000  \t   *  \n

3.  in named characters, the ht is the tab, the * is the asterisk, and
the nl is the newline:

$ od -a file
0000000  ht   *  nl

(See also man ascii, man od).

Now, imagine that this line is the subject of a patch ... that is, some
program like diff or darcs is generating a patch file to show how to
change this line from one version of a file to another.

Imagine that the person making the change adds a space and the word
hello to the end of the line, so that it becomes tab, asterisk, space,
hello ... like so:

	* hello

(which od(1) would show as 09 2a 20 68 65 6c 6c 6f 0a)

All very well and good, but as it is part of a diff generated patch, it
will have a "-" (what was there) and "+" (what is to be there) section,
and those have a trailing space.  So the patch band generated by diff
will look like this:

--- file.orig   2006-06-29 21:26:33.000000000 +1000
+++ file        2006-06-29 21:26:40.000000000 +1000
@@ -1 +1 @@
- 	*
+ 	* hello

(the last two lines are 2d 20 09 2a 0a 2b 20 09 2a 20 68 65 6c 6c 6f 0a)

That second line is plus, space, tab, asterisk, space, hello.  But
because a tab lines up to the next 8-column multiple, the asterisk does
not seem to move.  Provided you are looking at this on a character cell
display that properly indents tabs to the next 8-column multiple!
xterm, konsole, mutt, and emacs all do this for me.

Now imagine that in making the change, you changed the tab to eight
spaces.  Here is how it would look:

--- file.orig   2006-06-29 21:26:33.000000000 +1000
+++ file        2006-06-29 21:28:38.000000000 +1000
@@ -1 +1 @@
-       *
+        * hello

You see?  There is a clear misalignment.  The first line is minus,
space, tab, asterisk, but the second line is plus, space, eight spaces,
asterisk, space, hello.  The eight spaces don't have the same visual
effect as the tab, *only* because this is part of a patch.  The "+" and
space added by the patch causes the difference to be more visible.

> I'll also know when it looks different in darcs, it is
> referring to spaces/indent changes...

If you think it might be spaces or indent changes, one of the ways you
can prove it is do a diff with --ignore-all-space (or -w) between a copy
of the repo before your patch and the repo that has your patch.  Darcs
doesn't let me use -w on diff, but that doesn't stop me using diff

> I've never written code for someone else to see
> before. So this is an experience in of in itself. 

Writing for others changes your code ... giving it a higher value.  It's
fantastic ... helping you to become better at it.

> Please don't apply patch, so that I can send another one that is more
> consistent. 


> > Problem: the patch name doesn't meet the STYLE
> > requirements, in that it
> > is not in user-visible NEWS style.  See "Darcs -
> > Patch Name and Long
> > Comment" in the STYLE file.
> Okay, I'm not sure what this means. But I'll read the
> STYLE file and figure it out. 

I'll put it another way just in case.

When you type "darcs record" you are prompted for the patch name.  We
want you to use a name that matches what you would type into the NEWS
file if you were the maintainer of the NEWS file.  We will be using the
patch name later to build the NEWS file for the next release.

This also makes it very clear to anyone reviewing your patch exactly
what it does as far as the user (or player) is concerned.

Read the STYLE file.  If there is anything in there you don't
understand, then that is a program source code fault ... in the English
language ... so I'll be happy to fix it.

James Cameron    mailto:quozl at
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url :