FreeTDS Development Group

["Lowden, James K" <LowdenJK AT bernstein.com>]

> From: Castellano, Nicholas [mailto:Nicholas_Castellano AT acml.com]
> Sent: October 28, 2002 11:26 AM
>
> Indentation levels are not the same thing as tab stops, and 
> that is the problem I am trying to straighten out here.

I take your point. 

> Your implication that these changes were "harmful" is absurd. 
> Read the change log entry and think again.

Fair enough.  No harm done, at least not by you.  

> All I'm trying to do is find something that we all can live with.

Me too.  

> I don't
> understand why you seem to be hell-bent on specifying a bunch 
> of formatting
> options that simply will not render properly on the majority 
> of terminals.

I think Brian's statements on these questions deserve to be respected.  He
wants tabs, not spaces.  He wants them set at 5 postions, and he wants that
setting to guide primary indentation.  He's made himself quite clear on
those points.  I have my opinions, surely, which I offer (sometimes too)
freely, but I go along with what he says unless I can change his mind.  

Your opinion matters to me, too.  It's been known to change mine.  

> This is *not* a matter of taste.  It is an objective fact that our
> .indent.pro and our written documentation *do not* describe 
> the way the code
> appears on my terminal.  I attempted to change things so that we could
> retain the consensus decision of 5 spaces per indentation, while still
> allowing any terminal with any tab stop configuration to 
> render it in a consistent manner.  

Yes it is, as I defined taste.  Would you be satisfied if we changed our
documentation to say, "We set our editor's tabstop to 5, so the code will
look funny if viewed with more(1) on most terminals.  We know this is a
braindead decision, but we couldn't agree on anything better." ?  

CodingStyle says, "Indenting should be done with one tab character per
level.  I generally use a
tabstop of 5 when programming, so it probably looks best like that."  

I am openly honestly puzzled by the "default terminal setting" point of
view.  I thought it was a straw man.  I really really don't think it matters
how cat(1) renders our indentation.  Not at all, not even a little bit.  I'm
dumbfounded that you think it matters.  But perhaps you will find me
educable.  

To the extent that my opinion matters:

*  I would prefer almost any suggested alternative to the one currently
described by src/.indent.pro, including setting tabs to 8 and using an
indentation level of eight.  Maybe I'm all alone, but my editor isn't very
good at moving blocks of code in and out by spaces, and I never used the
"spaces for tabs" option in anything I've ever done.  
 
*  I would accept any indentation level and any tabstop, as long as tabs are
used for indentation.  Given others' expressed opinions, I lean to 4.  I
think it's easier to accomodate and accept a different tabstop setting than
to deal with blanks where tabs ought to be.  

*  I second your suggestion to change the line length to something bigger
than 80, say 100 or 132.  I think that would be doubly important if we agree
on an indentation level of 8.  See, I don't care what ANSI says about 80x24
terminals being standard.  

*  Brian has to say yes.  

You're saying indentation can be anything, but tabs have to be eight.  I
think that's an awkward way to work, and a radical departure from what
stands.  

I'm sorry I said you were doing anything harmful.  Sometimes your mail comes
across quite strong to me, and I took that the wrong way.  You didn't do
what I would have done, but there's no harm in that.  :)

Regards, 

--jkl


The information contained in this transmission may contain privileged and
confidential information and is intended only for the use of the person(s)
named above.  If you are not the intended recipient, or an employee or agent
responsible for delivering this message to the intended recipient, any
review, dissemination, distribution or duplication of this communication is
strictly prohibited. If you are not the intended recipient, please contact
the sender immediately by reply e-mail and destroy all copies of the
original message. Please note that we do not accept account orders and/or
instructions by e-mail, and therefore will not be responsible for carrying
out such orders and/or instructions.