On Mon, 14 Aug 2006 10:22:29 -0700, Walter Bright wrote:

> Oskar Linde wrote:
>> Today, the benefits are not as clear... :)
> 
> It finds all the bugs in your text processing code where you forgot to include \t in your whitespace checking!

isspace()?

-- 
Derek Parnell
Melbourne, Australia
"Down with mediocrity!"

Derek Parnell wrote:
> On Mon, 14 Aug 2006 18:24:05 +0200, Oskar Linde wrote:
> 
>  
>> This is how Emacs works and has worked for ages. Tabs are not directly used for indentation, but rather for optimizing the number of spaces needed. I guess at some time in the past, those 7 bytes saved here and there were well worth it. It would probably improve output speed on old teletypes and save memory at the same time. Those old teletypes could not redefine the tab stops anyway (well, I know the modern vt100 could, but not the vt52 afaik), so any other use for the tab character wasn't realistic.
>>
>> Today, the benefits are not as clear... :)
> 
> Thus my reference to "being locked into the past". The need for this style
> is no longer needed and hasn't been needed for quite awhile now. But
> habits, good and bad, are hard to break.

With emacs, breaking this particular bad habit is as simple as (setq-default indent-tabs-mode nil) :-)

Sean

On Mon, 14 Aug 2006 10:27:11 -0700, Walter Bright <newshound@digitalmars.com> wrote:
> Frits van Bommel wrote:
>> Oh, and if you prefer 8-space indentation, I'd like to suggest you use hard tabs (consistently!) so others can easily view it at 4 spaces (or whatever their personal preference may be).
>
> My screen ain't wide enough for that.

Sure it is. Your preference is for 4 space wide indentation, all you have to do is tell your editor to display a hard tab as 4 spaces (as any editor worth it's salt can do) and use hard tabs everywhere.

Problem #1 solved.

In fact, if you do this and discover some code is too wide for 4 space indentation, simply set tabs to 2 spaces (temporaily) to read that code, then set it back. Isn't that nice? and flexible?

I suspect if you print this code, and the editor sends actual hard tabs to the printer they'll probably be 8 spaces wide.. but:
1. who prints code?!?
2. the editor _should_ instead send your specified # of spaces instead of hard tabs.

Problem #2 solved.

Oh, and for those who want to align text on seperate lines remember the golden rule; "hard tabs first, spaces following" and you'll have no problems. Regardless of the viewers tab width the lines will align. (ignoring non fixed-width fonts, for which no solution involving spaces/tabs will work).

Problem #3 solved.

Regan

Sean Kelly wrote:
> Jarrett Billingsley wrote:
>> "Walter Bright" <newshound@digitalmars.com> wrote in message news:ebp2j7$1o5c$1@digitaldaemon.com...
>>
>>> It works just fine when you set tabs to be 8 characters, as god intended them to be.
>>
>> Or, you could just set them to 4 characters, and always use tabs.  Then everyone would be able to control the indentation as much as they want. That's the whole point of using hard tabs in a modern editor. 
> 
> Hard tabs work okay for leading indentation, but for inner indentation--long function calls, if statements, variable lists, etc--they can render code unreadable if viewed with a different tab width.  Even worse is if in a group project, some people use hard tabs and others spaces, and those using hard tabs have different tab widths.  I've worked on projects like this (including the one I'm on now) and the tabs are a disaster.  Given the relative ease with which modern editors can jump from word to word and eat whitespace, I simply don't understand the attachment to hard tabs.
> 
> 
> Sean

I'm not too keen on using tabs in inner indentation, for reasons like that. But for start-of-line indentation, hards tabs is the way to go. (with a width choice of 4 characters)


-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D

On Mon, 14 Aug 2006 09:14:04 -0700, Sean Kelly <sean@f4.ca> wrote:
> Jarrett Billingsley wrote:
>> "Walter Bright" <newshound@digitalmars.com> wrote in message news:ebp2j7$1o5c$1@digitaldaemon.com...
>>
>>> It works just fine when you set tabs to be 8 characters, as god intended them to be.
>>  Or, you could just set them to 4 characters, and always use tabs.  Then everyone would be able to control the indentation as much as they want. That's the whole point of using hard tabs in a modern editor.
>
> Hard tabs work okay for leading indentation, but for inner indentation--long function calls, if statements, variable lists, etc--they can render code unreadable if viewed with a different tab width.  Even worse is if in a group project, some people use hard tabs and others spaces, and those using hard tabs have different tab widths.

Simple; don't use hard tabs for internal* spacing, only for leading indentation. Use spaces for internal spacing.

* meaning in the middle of a line of text.

>   I've worked on projects like this (including the one I'm on now) and the tabs are a disaster.  Given the relative ease with which modern editors can jump from word to word and eat whitespace, I simply don't understand the attachment to hard tabs.

The attraction is the flexibility to view the code with your preferred indentation width/size. It's like defining your constant values at the top of your source, eg.

const int TAB_WIDTH = 4;

and using that integer in the code, instead of using the literal value '4'.

Regan

Regan Heath wrote:
> On Mon, 14 Aug 2006 10:27:11 -0700, Walter Bright <newshound@digitalmars.com> wrote:
>> Frits van Bommel wrote:
>>> Oh, and if you prefer 8-space indentation, I'd like to suggest you use hard tabs (consistently!) so others can easily view it at 4 spaces (or whatever their personal preference may be).
>>
>> My screen ain't wide enough for that.
> 
> Sure it is. Your preference is for 4 space wide indentation, all you have to do is tell your editor to display a hard tab as 4 spaces (as any editor worth it's salt can do) and use hard tabs everywhere.
> 
> Problem #1 solved.
> 
> In fact, if you do this and discover some code is too wide for 4 space indentation, simply set tabs to 2 spaces (temporaily) to read that code, then set it back. Isn't that nice? and flexible?
> 
> I suspect if you print this code, and the editor sends actual hard tabs to the printer they'll probably be 8 spaces wide.. but:
> 1. who prints code?!?

I do. I also put code in html <pre>...</pre>, where tabs are 8. I put code in emails, where tabs are 8. I print code on the console, where tabs are 8. I send code to other operating systems, where tabs are 8.

> 2. the editor _should_ instead send your specified # of spaces instead of hard tabs.
> 
> Problem #2 solved.

Send it to where? The disk file? Then there aren't tabs in it anymore.

> Oh, and for those who want to align text on seperate lines remember the golden rule; "hard tabs first, spaces following" and you'll have no problems. Regardless of the viewers tab width the lines will align. (ignoring non fixed-width fonts, for which no solution involving spaces/tabs will work).
> 
> Problem #3 solved.

Not really, because I follow that rule, and if tabs are set to 3 it gets all screwed up.

Derek Parnell wrote:
> Secondly, I too use such equipment and software and I don't have any issue
> with using hard-tabs, because I don't use tabs.

That is a workable solution, but I like using tabs. They make me more productive at the keyboard.

The real problem is the folks who set their *hard* tab stops at something other than 8. This is just a mistake. There's no problem in a decent editor to set the *soft* tab stops to 3, or whatever. Just not the hard ones.

Are we really having this debate.  Might as well start on editor wars and who's languages is better than.. oh wait, this is a D forum, so at least we can skip _that_ one.

There's got to be better ways to expend this sort of energy. :)

Regan Heath wrote:
> 
> Oh, and for those who want to align text on seperate lines remember the golden rule; "hard tabs first, spaces following" and you'll have no problems. Regardless of the viewers tab width the lines will align. (ignoring non fixed-width fonts, for which no solution involving spaces/tabs will work).

What about:

    int x,
        y,
        z;

    if( x == y ||
        y == z )
    {
        func( x,
              y,
              z );
    }

Changing tab widths can totally mess up this sort of thing if tabs were involved in the creation of any of the involved lines.  Things get even worse if some lines were indented with spaces and others with tabs. I'll admit that none if this is a problem for solo projects, but in a group it can be a disaster.  And maybe you can enforce indenting rules to this level of detail, but I can't :-)


Sean

Walter Bright wrote:
> Regan Heath wrote:
>>
>> I suspect if you print this code, and the editor sends actual hard tabs to the printer they'll probably be 8 spaces wide.. but:
>> 1. who prints code?!?
> 
> I do. I also put code in html <pre>...</pre>, where tabs are 8. I put code in emails, where tabs are 8. I print code on the console, where tabs are 8. I send code to other operating systems, where tabs are 8.

Only by default.  The first thing I do when configuring an editor is change the tab width to 4.  8 chars is simply too wide IMO, even for paragraph indentation.

>> 2. the editor _should_ instead send your specified # of spaces instead of hard tabs.
>>
>> Problem #2 solved.
> 
> Send it to where? The disk file? Then there aren't tabs in it anymore.

Right.  But is that a problem?  I'll admit it's a tiny time-saver to be able to move through tab-filled regions with the cursor, but it's just as easy (and even faster) to jump between words with control keys.

But all this is really a matter of opinion... which I guess is the point?  I've always favored using spaces because it preserves readability regardless of one's opinion of what the correct tab width is.


Sean