How to change the length of "\t"?

[James Kanze]

(e-mail address removed)>, (e-mail address removed)
says...

[ ... ]

Could you explain please. Starting with what use you see for
tabs.

Well, almost none, quite frankly...

Not really -- 8 was used there, but never worked worth a darn, IMO.

"worked" is relative. When your files are copies of Fortran
programs, on cards, with a serial number starting in column 72,
it could reduce the file size by half.

Of course, it's no where near as effective as gzip.

...and therefore, also a multiple of 4.

Yes, but when skipping from the end of the actual text to this
position, you only need half as many tab characters if they are
eight.

To be honest, I was thinking primarily in terms of people who
still use them for indenting code. For that purpose, I find
tab stops of 8 (regardless of whether implemented using actual
tab characters or by inserting spaces) to be quite unusable --
a pointless waste of space at best.

Tabs don't work here, regardless of the tab stop. What happens
when you look at the output of diff, or grep?

When I mostly wrote C, I'd have said it didn't matter much --
you should rarely have code nested deeply enough for it to
make much difference. In C++, however, quite a bit of code is
(for example) in a member function in a class in a namespace,
so you frequently end up with two or three levels of
indentation before you start writing code at all. Even a
perfectly reasonable level of indentation the code itself
(e.g. 2 deep) and your code is indented 40 spaces. Given that
I normally prefer to limit lines to no more than 72
characters, that leaves less than half the line available for
real use. More than once I've seen people shortening
identifiers to make things fit at that point, and IMO, that
fully merits being called "completely unusable".

Which raises the question: what should you indent, when. I
don't find myself indenting more in C++ than in C. If anything,
less, because C++ seems to lend itself to better encapsulation,
and smaller, simpler functions. But then, I don't indent for
the namespaces, and I don't define member functions in the
classes.

 

[Jerry Coffin]

[ ... using tabs ]

"worked" is relative. When your files are copies of Fortran
programs, on cards, with a serial number starting in column 72,
it could reduce the file size by half.

Of course, it's no where near as effective as gzip.

Even an incredibly simple RLE should work quite nicely for this...

[ ... ]

Tabs don't work here, regardless of the tab stop. What happens
when you look at the output of diff, or grep?

Oh, you're better off without tabs at all, no doubt about that. The
obnoxion is reduced (slightly) when they're four-stop instead of eight-
stop tabs though.

[ ... ]

Which raises the question: what should you indent, when. I
don't find myself indenting more in C++ than in C. If anything,
less, because C++ seems to lend itself to better encapsulation,
and smaller, simpler functions. But then, I don't indent for
the namespaces, and I don't define member functions in the
classes.

Hmm...I usually indent for namespaces, though I'll admit I don't feel
strongly about it. I frequently write member function definitions inside
of the class definition at first, and move them into separate files only
when/if I see a reason to do so.

 

[James Kanze]

* James Kanze:

It is of course the common practice for Windows that sets that
Windows de-facto standard; maintaining anything else is just
silly.

Well, that olde "standard" was tab size 8 or 10 (!), for printers.

That's true. If you go back far enough, 10 was in widespread
use as well. But practically speaking, before Windows or Unix,
all I've ever seen on computers was either 8, or fully
configurable. And before computers, it didn't matter, because
of course, what you got was always spaces; tab was just a
special key, but whether you typed so many spaces, or used the
tab key, made no difference in the document.

Dunno what you checked but obviously the Wrong Thing. ;-)

I created a file with a tab character in it, and viewed it (with
the "type" command---which is the most basic Windows you can
get, I think). The tab caused the text to be indented 8 spaces.

I just rechecked on my machine here: all of the programs which
are available for editing or displaying text seem to use 8:
"type" (from the command line), Notepad, Wordpad.

If there *is* a standard of 4, it seems to be limited to Visual
Studios. Although in the version which is installed here, it's
completely configurable: I can specify both the tab size and the
indent size, and specify that I want it to use spaces for
indentation. In sum, what I'd expect from any program text
editor. The default isn't really useful, but that's pretty much
the case for ever editor I've ever seen.

No, it isn't. Nearly all Microsoft code uses tab size 4. So
do nearly all Windows programmer's editors, and reportedly
that's also the case on the Mac.

All of my code uses an indentation of 4, too. But the files
don't contain a tab character.

He he. Everybody knows it's just CR. Nobody'd be fool enough
to use anything but a Mac.

. Everyone except ASCII, of course.

Actually, there were two widespread practices before Unix:
CR,LF, and LF,CR. According to ASCII, both should give the same
results. (I've never tried LF,CR on either Unix or Windows,
though.)

Wikipedia, which as we all know is the final arbiter of such
questions, the highest authority[1], says "it is unclear why
the 8-character horizontal size was chosen [for printers], as
5 characters, half inch in a typical printer at that time [no
reference or timeframe given], was much more popular at that
time as a paragraph indentation. It may have been chosen to
match early Fortran conventions for where the statement text
started after the line number and continuation character. Or
it may have been chosen as the smallest size that would fit
numbers typically printed in a table."

Well, I seem to remember the 10 you mentioned as the default on
typewriters, back then. And since computer scientists insist on
everything being a power of 2, 8 is the closest power of 2.

Only for cross-platform code. For Windows programming you'd
have a very hard time if you didn't tackle tabs, since MS's
code uses them. And since you have to tackle them anyway, it
would be silly to give up the benefits (yes, there are).

Who looks at MS's code? More generally, I've seen code from
many different sources, and a lot does use tabs. But not always
the same: I've seen 2, 3, 4 and 8. Worse, I've seen code where
parts were obviously written using one tab setting, and other
parts using a different tab setting; you had to change the
configuration of your editor depending on which function, or in
a couple of cases, which part of the function, you wanted to
display correctly.

Under Windows... What do the Windows equivalents of grep and
diff do with tabs, when they display?

On *nix. In Windows (and presumably on the Mac) the problem is
when an editor displays existing tab characters as if tab
stops were anything else but 4. Makes havoc of the existing
code you have to relate to.

Doesn't that depend on what existing code you're talking about.
Obviously, if you've been using tab stops to indent, you don't
want to change the editor configuration until you've untabified
them. Of course, if you've done it right to begin with, this
isn't a problem.

If you're dealing with an external library which is so poorly
documented you have to look at the sources, then this depends on
the library. But what Microsoft may or may not do isn't an
issue here, since Microsoft's libraries (at least those I've
looked at) are very well documented.

Not sure what the imagined problem would be.

Tools like diff and grep output lines from your code with some
additional characters in front of them. Which messes up any
indentation using tabs.

Yes, yes, for cross-platform code, certainly.

Since there's no hope of ever convincing *nix folks to give up
the stupid 8 positions per tab stop convention, and adopt the
much more rational 4. <g>

It's not really a question of Unix. The convention was too well
established even before Unix came along for it to be possible to
change it.

 

[Pascal J. Bourguignon]

. Everyone except ASCII, of course.

Actually, there were two widespread practices before Unix:
CR,LF, and LF,CR. According to ASCII, both should give the same
results. (I've never tried LF,CR on either Unix or Windows,
though.)

They would give the same result on a glass tty, but not on a normal
teletype. There, if you send LF, and then CR, the first characters of
the following lines would be printed in the middle of th eline,
because CR takes more time to move the carriage from the right side to
the left side, than LF takes time to move up the paper. That's why
you should always use CR-LF, and not LF-CR, and when you're on a unix
system, convert LF to CR-LF, and when you are on a MacOS system,
convert CR to CR-LF.

It's not really a question of Unix. The convention was too well
established even before Unix came along for it to be possible to
change it.

The best thing to do is to ban the TAB control code in your text
files. Always use spaces to indent or align columns. Any good editor
(eg. emacs) will have an option to do so.

 

[James Kanze]

They would give the same result on a glass tty, but not on a
normal teletype. There, if you send LF, and then CR, the
first characters of the following lines would be printed in
the middle of th eline, because CR takes more time to move the
carriage from the right side to the left side, than LF takes
time to move up the paper.

You mean less time, I think.

That's why you should always use CR-LF, and not LF-CR, and
when you're on a unix system, convert LF to CR-LF, and when
you are on a MacOS system, convert CR to CR-LF.

And have a similar problem with some other printer, which works
differently. It was long known that with some hardware, you
needed to output padding characters after certain functionality,
in order to ensure that it finished; CR was one of these on a
teletype. (Of course, the reason CR before LF came to be
prefered was because the LF counted as one of those padding
characters on a teletype. So you gained a character. At, what
was it, 120 baud, that made a difference.)

The best thing to do is to ban the TAB control code in your
text files. Always use spaces to indent or align columns. Any
good editor (eg. emacs) will have an option to do so.

That's what I've been saying, and it seems to be the one point
everyone agrees with. (And of course, not only emacs, but vim
and the Visual Studios program editor, to name two others,
support this.)