Re: How to change the length of "\t"?
On Jul 15, 11:17 pm, "Alf P. Steinbach" <al...@start.no> wrote:
* James Kanze:
On Jul 15, 7:01 pm, "Alf P. Steinbach" <al...@start.no> wrote:
* James Kanze:
Using anything other than 8 for tabstops is a dumb thing,
since that's the universal defacto standard today (and you
certainly don't look at text only in an editor).
I'm sorry, but that's not correct. The de facto Windows
standard is 4 character positions per tab stop. Tools from
early eighties (e.g. Notepad) excepted.
Windows doesn't make the standard
It is of course the common practice for Windows that sets that
Windows de-facto standard; maintaining anything else is just
silly.
it was established long before windows appeared.
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.
And a quick check on my Windows machine showed it using 8 as
well (under Windows XP).
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.
So I'm not sure what you're talking about when you speak of
4; until your statement above, I had assumed that it was a
personal configuration of the editor.
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.
If they did try to make it 4... Trying to change such an
established standard is almost as dumb as another systems
attempt to change the de facto standard for line endings
(which is, of course, CR,LF).
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.)
Regarding what's dumb, the *nix de facto standard of 8
character positions per tab stop is clearly dumb, since it's
impractical for anything,
Historically, I don't know where the 8 comes from; it was the de
facto standard before I got into computer programming, and that
goes back some. Before Windows or Unix.
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.
and the lack of a standard for indicating the tab stop and
indentation settings of source code is clearly dumb (would be
a good candidate for a new C++ preprocessor directive :-)).
But I'm pretty sure that folks who have not enjoyed the
benefits of working in an environment with consistent 4-tabs,
actually using tabs in source code, will not immediately grasp
why any of the abovementioned should be dumb. After all, we
manage quite fine without using tabs at all, thank you.
Yes. You shouldn't use tabs in your source code; that much is
clear.
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?
And there's no problem with an editor doing whatever it
wants with the tab key (emacs reindents the line according to
its idea of how it should be indented). The problem is when the
editor (or any other program) inserts a tab character in the
code, or displays an existing tab character as if tab stops were
anything else but 8.
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.
If you're using an indentation other than 8 (and 8 is too
big), then you have to use some spaces for the indentation.
(Because people are stupid enough to set tabstops in their
editor at something different than 8, I've given up using
tabs at all in text files. Just spaces, so everyone will
see the code as it was meant to be formatted.)
Using spaces instead of tabs is a good recommendation for
cross-platform work, and it is, for example, the solution
adopted by Boost.
Not just cross platform. It comes into play anytime you do a
diff or whatever Windows equivalent of grep is. (I'll admit
that I'm lazy---rather than learn the Windows tools for such
essential tasks, I just installed a Unix tool kit. Which is far
from ideal, but since I already know it, and don't work enough
under Windows to justify learning anything else...)
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.
Letting the editor indent however much you want (I like four,
but three or five is also acceptable) is also a good thing; just
get everyone on the project to agree. And make sure that when
the indentation gets into the files, it's as spaces, not tab
characters, or you'll run into problems downstream.
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.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34