[ On , September 29, 1999 at 08:15:50 (-0700), Chris G. Demetriou wrote: ]
> Subject: Re: CVS commit: syssrc
>
> woods@most.weird.com (Greg A. Woods) writes:
> > In this particular case I've never ever been shown any rational for
> > using a tab.  The only one I've ever been able to imagine is that if you
> > have a collection of #define and #undef lines interleaved together then
> > it might be nice to have the second token alligned and thus a tab before
> > every token would be the most consistent form.  However I never mix a
> > group of #define and #undef lines.
> 
> Another that's nice is that they do the right thing re: alignment, for
> diffs.

I've learned never to worry about alignment in diffs.  If I really want
to see the code in its proper form I apply the diff to a temporary file
and look at that.

<SOAPBOX>
If people think such alignment is critical then they should teach diff
to show a tab before each line instead trying to hack their own code
style to suite just one potential form of viewing it.  Indeed this is a
personal taste thing, but except for the apparent waste of visual space,
a tab is the only correct way to preserve other tabs in the line when
you want to indent something (such as in diff output).  I really do not
now, nor have I ever, had the time of day for restrict-to-80-column
nuts.  In the old days we had 132-column printers and 132-column
displays on advanced terminals such as VT100's.  These days we have
17-inch or better monitors and decent small but readable fonts.
Standard 8-space tabstops and one tab per indentation shouldn't impair
annyone's ability to read the code (unless they're on a C-64 terminal
emulator! ;-), and as such an extra tab in diff output shouldn't hurt,
and in fact will help.
</SOAPBOX>
 
> but if you use spaces instead of the tabs after the #defines you get:
> 
>   #define foo   baz     
>   #define barfoo        baz
 
In my suggestion the diff output becomes:

<tab>#define foo<tab>baz
<tab>#define barfoo<tab>baz
+<tab>#define<tab>none<tab>blitz
<tab>#define bob<tab>boop
<tab>#define bill<tab>bong
 
i.e.:

	#define foo	baz
	#define barfoo	baz
+	#define	none	blitz		/* a new thing */
	#define bob	boop
	#define bill	bong

or for the tab-imparied:

        #define foo     baz
        #define barfoo  baz
+       #define none    blitz           /* a new thing */
        #define bob     boop
        #define bill    bong

In this case you'll see that it matters not whether there's a tab after
the #define.

Note that this also helps preserve columnar output if there are multiple
tabs on the same line, such as with the outdented comment.

ASCII tab characters are an unfortunate invention that have caused more
than enough troubles.  I'd really like to get rid of them but I'm too
much of a miser to store all the extra space characters so I've learned
to always deal with them in the de facto way with 8-space stops.
Ideally tabs should be an X3.64 escape sequence that always specifies
the position to tab to and no assumptios should ever have been made
about preset tab-stops.  But that's just blue-sky dreams at this late
date....

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>