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 changed. 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 command: $ 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 myself. > 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. Agreed. > > 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 us.netrek.org http://quozl.netrek.org/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20060629/e4db1fae/attachment-0001.pgp