FreeTDS Development Group

["Castellano, Nicholas" <Nicholas_Castellano AT acml.com>]

OK, then let's take another look at some of Brian's most recent comments.

"Anyway, I'll weigh in with my thoughts (although don't feel I have any more
weight than anyone else)."

I take that to mean that he's open to the group coming to a reasonable
consensus about all of these issues.  Of course all of us are likely to give
Brian's opinions more weight whether he likes it or not.

"I like tabs.  Having to hit space multiple times to align code slows me
down tremendously.  I know there are ways to tie tab to produce multiple
spaces but that means I have to be modal when moving between projects
(invoking an alias to change behavior when I edit a FreeTDS file or a file
from another project)."

I agree with the issue of modality.  In fact, this is the main reason I'm
making an issue of all this.  I don't want to have two modes for my tab
stops, one for FreeTDS code and one for everything else.  (I've already
resigned myself to having to be modal about actually editing FreeTDS code;
this is unavoidable since we obviously won't be using my default coding
style.)

"Where character by character alignment is wanted, tabs are wholly
inappropriate."

Exactly my point!  Indented code is *full* of alignment issues like this,
and there's no avoiding it.

"Whether you use tabs or spaces for indention is moot because that is not
indention it's column alignment, if you get me.  I have no problem with tab
indenting and then using spaces to align, although some will surely argue
the aesthetics of that."

This is really a key point that deserves another look.  It's really the only
way that we could mix tabs and spaces, and have the results rendered
decently with any tab stop setting.  The problem is, as far as I know, there
are no automated indenting tools that divide the concepts of indentation and
alignment in quite this way.  And getting this consistently right all the
time is probably beyond the ability of most humans, too.  Certainly, the
conceptualization and calculation involved for each line is going to slow
anyone down more than just holding down the space bar for a few seconds
would.  So, I just don't think this is practical right now.

As I see it, there are two reasonable compromises.  I'd be happy with either
one.

- We use tab stops of 8.  Each indentation is one tab.  Precise column
alignment is (col / 8) * tab + (col % 8) * space.  Gindent appears to be
able to work this way (-ts8 -i8 -ut), and it will render properly on most
terminals.

- We use any random tab stop value (say 5 for the sake of argument), but
indentation is 5 spaces.  We never use tabs, so that we don't rely on any
particular terminal tab stop setting to render the code correctly.  Precise
column alignment is simply the number of spaces that it takes to line things
up.  (This is what I implemented last night in our .indent.pro, but I'd be
fine with the other option, and I suspect Brian might like that one better).

Of course, the third option is:

- Do something else entirely, and Nick will cope and deal.  If that's the
decision, I'm fine with it.  I just want the other options given reasonable
consideration and thought by all before we do this.  Freddy and I seem to
have already reached a consensus of two.  If I read you correctly, your
primary problem with all this is that you think Brian won't like it.  If
Brian simply can't live with what I implemented, I hope he will speak up and
let that be known.

Cheers,
--nick

-----Original Message-----
From: bounce-freetds-145195 AT franklin.oit.unc.edu
[mailto:bounce-freetds-145195 AT franklin.oit.unc.edu] 
Sent: Monday, October 28, 2002 1:09 PM
To: TDS Development Group
Subject: [freetds] RE: indent (next shot:) )


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



---
You are currently subscribed to freetds as: [Nicholas_Castellano AT acml.com]
To unsubscribe, forward this message to
$subst('Email.Unsub')


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.