FreeTDS Development Group

["Brian Bruns" <camber AT ais.org>]

Nick/Jim

tabstop of 8 is completely fine with me.  I keep mine at 5 but that is a
completely personal decision.  Anything indented with one tab at 8 will
look fine at 5.  The reverse is not always true as we sometimes will hit
the 80 char line limit and 5->8 will be wrapped awkwardly.

If we are madly wrapping over the line because of too many levels of
indention it's usually a good indication that the function needs to be
split up a bit anyway, so I don't see any particular drawbacks to tabs at
8.

Anyway, let's just decide something and put this issue to bed.

Brian

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