Skip to Content.
Sympa Menu

freetds - RE: indent (next shot:) )

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: "Brian Bruns" <camber AT ais.org>
  • To: freetds AT franklin.oit.unc.edu
  • Subject: RE: indent (next shot:) )
  • Date: Mon, 28 Oct 2002 14:43:08 -0500


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
>




Archive powered by MHonArc 2.6.24.

Top of Page