FreeTDS Development Group

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

Good enough for me.  I have committed a new .indent.pro with "-ts8 -i8 -ut".

I think the last detail to be worked out before we roll with this, is the
line length.  Rigth now we have "-l80".  We can leave it as is.  We can go
back to "-l75" (Freddy's suggestion).  We can go to "-l132" (Jim's
suggestion).  We could even remove it completely, and impose no maximum line
length restriction.

I'm fine with any of those options...it's easy enough to resize an xterm to
132, or whatever.  If anyone has a strong opinion on this, speak up before
it's too late!

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 2:43 PM
To: TDS Development Group
Subject: [freetds] RE: indent (next shot:) )


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
> 

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