Tab indentions on different platforms?

[xkenneth]

All,
I seem to be having problems with running my python code, written
on a Mac, on Linux and Windows boxes. It seems like the problem has to
do with tab indention, particularly I've noticed that my code will
completely ignore try statements. Has anyone had a similar problem?

Regards,
Ken

[John Machin]

On Dec 29, 9:51 am, xkenneth <[e-mail]:

I seem to be having problems with running my python code, written
on a Mac, on Linux and Windows boxes.

So *what* problems do you seem to be having? More to the the point,
what problems are you *actually* having?

It seems like the problem has to
do with tab indention, particularly I've noticed that my code will
completely ignore try statements. Has anyone had a similar problem?

Yes.

Set up your text editor to (a) recognise Tab and Shift-Tab keyboard
inputs as indent/dedent respectively and (b) to insert 4 spaces and
zero tab characters per indent. IOW, don't have tab characters at all
in your source files.

If after that you still have a problem, ask here again, with the
following information:

1. The shortest possible script file that reproduces the problem --
use
print open('problemdemo.py', 'rb').read()
to show the contents (a) as it appears on the Mac (b) after
transferring [how?] to Linux (c) after transferring [how?] to Windows

2. The results of executing the code in each of the three environments
-- copy/paste of the actual output, not a description.

[Thorsten Kampe]

* xkenneth (Fri, 28 Dec 2007 14:51:04 -0800 (PST))

I seem to be having problems with running my python code, written on
a Mac, on Linux and Windows boxes.

You seem to have problems or you do have problems?

It seems like the problem has to do with tab indention,

Why does it seem and what does seem?

particularly I've noticed that my code will completely ignore try
statements.

Statements are never ignored: they error or they don't.

Has anyone had a similar problem?

It doesn't matter how a particular editor (note, that's not an OS
thing!) displays indents. If you use only tabs or spaces that's just
fine. I'd personally go for spaces because:

1. I don't like things I cannot see (control characters)

2. I never had problems with spaces but plenty with tabs
Thorsten

[Steven D'Aprano]

On Sat, 29 Dec 2007 15:29:25 +0000, Thorsten Kampe wrote:

I'd personally go for spaces because:

1. I don't like things I cannot see (control characters)

You can see spaces but not tabs? Your editor is pretty weird. In all the
editors I've every used, both spaces and tabs show up as empty white
space. (Or coloured space if I set the editor to use a coloured
background.)

2. I never had problems with spaces but plenty with tabs

Periodically, I ask on this list what problems people have with tabs.
(I'm fully aware that mixing tabs and spaces is a Bad Thing.) I've had
little luck getting any answer except "Tabs are bad, m'kay?".

I'm only aware of two problems that some people run into due to the
consistent use of tabs rather than spaces.

* Some news clients don't display tabs correctly, thus making it hard to
copy and paste code direct out of the news reader into your source;

(But of course if you copy code using spaces, and the number of space
characters used per indent level doesn't match your source code, you'll
have problems too.)

* Some applications "helpfully" convert tabs into spaces, thus meaning
that when copy code from them, you end up with spaces instead of tabs.

What problems have you had with tabs that aren't related to buggy
applications or users that mix tabs and spaces?

--
Steven

[Ben Finney]

Steven D'Aprano <st***@REMOVE-THIS-cybersource.com.auwrites:

On Sat, 29 Dec 2007 15:29:25 +0000, Thorsten Kampe wrote:

I'd personally go for spaces because:

1. I don't like things I cannot see (control characters)

You can see spaces but not tabs? Your editor is pretty weird. In all
the editors I've every used, both spaces and tabs show up as empty
white space. (Or coloured space if I set the editor to use a
coloured background.)

Though Thorsten could have been clearer, "thing that is not a space
character but shows up as white space" is a near-enough approximation
of "thing I cannot see".

2. I never had problems with spaces but plenty with tabs

Periodically, I ask on this list what problems people have with
tabs. (I'm fully aware that mixing tabs and spaces is a Bad Thing.)
I've had little luck getting any answer except "Tabs are bad,
m'kay?".

Posit: White space is most often achieved by the user inserting a
sequence of space characters (U+0020).

Posit: Tab characters (U+0009) are, in a majority of environments,
rendered visually indistinguishable from a sequence of space
characters.

Corollary: most readers will, when seeing a stretch of white space on
a line, default to assuming that it represents a sequence of space
(U+0020) characters.

Corollary: So when a file containing either spaces or tabs is edited
in such an environment, the common way chosen by the user to get to
the same indentation level as existing lines is to prepend space
characters (using the spacebar or the Tab key or whatever facility the
editor provides) until the indentation lines up visually --
remembering the caveat that tabs and space-sequences are visually
indistinguishable in many environments.

Argument: The user will get an unexpected result when they do the
obvious thing (prepend space characters) in a tabs-only file. With
existing spaces-only files, the obvious way to get matching
indentation gives the expected result.

Conclusion: Thus, using tabs-only is inferior to using spaces-only for
indentation, because it violates the Principle of Least Astonishment
<URL:http://en.wikipedia.org/wiki/Principle_of_least_astonishment>.

--
\ "I object to doing things that computers can do." —Olin |
`\ Shivers |
_o__) |
Ben Finney

[John Nagle]

Thorsten Kampe wrote:

* xkenneth (Fri, 28 Dec 2007 14:51:04 -0800 (PST))

>I seem to be having problems with running my python code, written on
a Mac, on Linux and Windows boxes.

You seem to have problems or you do have problems?

>It seems like the problem has to do with tab indention,

It really should be a syntax error in Python to mix
leading tabs and leading spaces in the same file. One can argue over
which to use, but a file with both usually leads to trouble.

John Nagle

[John Machin]

On Dec 30, 3:48 pm, John Nagle <[e-mail]:

Thorsten Kampe wrote:

* xkenneth (Fri, 28 Dec 2007 14:51:04 -0800 (PST))

I seem to be having problems with running my python code, written on
a Mac, on Linux and Windows boxes.

You seem to have problems or you do have problems?

It seems like the problem has to do with tab indention,

It really should be a syntax error in Python to mix
leading tabs and leading spaces in the same file. One can argue over
which to use, but a file with both usually leads to trouble.

It can be made to do so:

promptpython -h
usage: python [option] ... [-c cmd | -m mod | file | -] [arg] ...
Options and arguments (and corresponding environment variables):
[snip]
-t : issue warnings about inconsistent tab usage (-tt: issue
errors)
[snip]

Further advice to the OP: run python with the -t (or -tt) option and
see what you get.

[Thorsten Kampe]

* Steven D'Aprano (Sun, 30 Dec 2007 00:37:32 -0000)

On Sat, 29 Dec 2007 15:29:25 +0000, Thorsten Kampe wrote:

I'd personally go for spaces because:

1. I don't like things I cannot see (control characters)

You can see spaces but not tabs? Your editor is pretty weird. In all the
editors I've every used, both spaces and tabs show up as empty white
space.

That's because the editor displays those invisible tab control
characters as something they're not: spaces.

2. I never had problems with spaces but plenty with tabs

What problems have you had with tabs that aren't related to buggy
applications or users that mix tabs and spaces?

Fortunately I don't remember every incident when I stumbled about
something weird behaving or looking. One thing I do remember is
reading python source code (not my own) with a pager. The source code
was badly indented. The pager was not "buggy".

Thorsten

[Thorsten Kampe]

* Ben Finney (Sun, 30 Dec 2007 15:36:12 +1100)

Steven D'Aprano <st***@REMOVE-THIS-cybersource.com.auwrites:

On Sat, 29 Dec 2007 15:29:25 +0000, Thorsten Kampe wrote:

I'd personally go for spaces because:
>
1. I don't like things I cannot see (control characters)

You can see spaces but not tabs? Your editor is pretty weird. In all
the editors I've every used, both spaces and tabs show up as empty
white space. (Or coloured space if I set the editor to use a
coloured background.)

Though Thorsten could have been clearer, "thing that is not a space
character but shows up as white space" is a near-enough approximation
of "thing I cannot see".

2. I never had problems with spaces but plenty with tabs

Periodically, I ask on this list what problems people have with
tabs. (I'm fully aware that mixing tabs and spaces is a Bad Thing.)
I've had little luck getting any answer except "Tabs are bad,
m'kay?".

Posit: White space is most often achieved by the user inserting a
sequence of space characters (U+0020).

Posit: Tab characters (U+0009) are, in a majority of environments,
rendered visually indistinguishable from a sequence of space
characters.

Corollary: most readers will, when seeing a stretch of white space on
a line, default to assuming that it represents a sequence of space
(U+0020) characters.

Corollary: So when a file containing either spaces or tabs is edited
in such an environment, the common way chosen by the user to get to
the same indentation level as existing lines is to prepend space
characters (using the spacebar or the Tab key or whatever facility the
editor provides) until the indentation lines up visually --
remembering the caveat that tabs and space-sequences are visually
indistinguishable in many environments.

Argument: The user will get an unexpected result when they do the
obvious thing (prepend space characters) in a tabs-only file. With
existing spaces-only files, the obvious way to get matching
indentation gives the expected result.

Conclusion: Thus, using tabs-only is inferior to using spaces-only for
indentation, because it violates the Principle of Least Astonishment
<URL:http://en.wikipedia.org/wiki/Principle_of_least_astonishment>.

Man, how did you know what I wanted to say (but failed to to express)
:-) ? Anyway: the consequence of your well done argumentation is that
someone editing Python code has to use a specialised editor to prevent
screwing up tab indented code - and that's bad.

Thorsten

[Steven D'Aprano]

On Sun, 30 Dec 2007 20:33:19 +0000, Thorsten Kampe wrote:

* Steven D'Aprano (Sun, 30 Dec 2007 00:37:32 -0000)

>On Sat, 29 Dec 2007 15:29:25 +0000, Thorsten Kampe wrote:

I'd personally go for spaces because:

1. I don't like things I cannot see (control characters)

You can see spaces but not tabs? Your editor is pretty weird. In all
the editors I've every used, both spaces and tabs show up as empty
white space.

That's because the editor displays those invisible tab control
characters as something they're not: spaces.

Editors display tab characters as "indent to next tab stop". That's what
they're for, and any editor that doesn't behave that way is buggy.

Tab characters are no more invisible than space characters. How can you
see space characters but not tabs? Why aren't space characters invisible
too? Why do you dislike tabs *specifically* because they are invisible,
but like invisible spaces?

2. I never had problems with spaces but plenty with tabs

What problems have you had with tabs that aren't related to buggy
applications or users that mix tabs and spaces?

Fortunately I don't remember every incident when I stumbled about
something weird behaving or looking. One thing I do remember is reading
python source code (not my own) with a pager. The source code was badly
indented. The pager was not "buggy".

Given the constraints of the typical pager one-line display, and the
tendency of pagers I've seen to arbitrarily drop leading whitespace *of
any sort* from the start of lines, I'd like to know how you could tell
the indentation was wrong.

If the source code was correctly indented, but displayed wrongly by the
pager, then of course the pager was buggy. And if the source code was
incorrectly indented and the pager showed it as it was, well, that can
happen with spaces too:

x = 1
for i in range(20):
x += i
print x
No tabs there, all the indentation is done with spaces. How would you
expect a pager to display that?

--
Steven

[Steven D'Aprano]

On Sun, 30 Dec 2007 20:41:09 +0000, Thorsten Kampe wrote:

Anyway: the consequence of your well done argumentation is that
someone editing Python code has to use a specialised editor to prevent
screwing up tab indented code - and that's bad.

You just need to use an editor that inserts tab characters when the tab
key is pressed, just like you use an editor that inserts s characters
when the s key is pressed. If people didn't insist on using spaces where
tabs are called for, there would be no problem, and you wouldn't need a
specialized editor to prevent screwing up space-indented code.

--
Steven

[Ben Finney]

Steven D'Aprano <st***@REMOVE-THIS-cybersource.com.auwrites:

On Sun, 30 Dec 2007 20:41:09 +0000, Thorsten Kampe wrote:

Anyway: the consequence of your well done argumentation is that
someone editing Python code has to use a specialised editor to prevent
screwing up tab indented code - and that's bad.

You just need to use an editor that inserts tab characters when the
tab key is pressed, just like you use an editor that inserts s
characters when the s key is pressed.

No, that's not all you need to do. You also need to keep your code
away from the majority of programmers, who use their default editor in
its default settings, and who expect that horizontal whitespace is
produced by the U+0020 space character (even if they don't know the
specifics of the character coding).

Saying that the tabs-only argument and the spaces-only argument are of
equal value is philosophically true, but practically worthless.
They're of equal value *only* in isolated environments where you can
control the expectations of *every* programmer who will *ever* edit
the file.

To form an indentation policy based only on hypothetical
fully-controlled isolated environments is foolish, to say the least.

--
\ "If you can't beat them, arrange to have them beaten." -- |
`\ George Carlin |
_o__) |
Ben Finney

[Thorsten Kampe]

* Steven D'Aprano (Sun, 30 Dec 2007 23:28:50 -0000)

On Sun, 30 Dec 2007 20:33:19 +0000, Thorsten Kampe wrote:

* Steven D'Aprano (Sun, 30 Dec 2007 00:37:32 -0000)

On Sat, 29 Dec 2007 15:29:25 +0000, Thorsten Kampe wrote:
I'd personally go for spaces because:

1. I don't like things I cannot see (control characters)

You can see spaces but not tabs? Your editor is pretty weird. In all
the editors I've every used, both spaces and tabs show up as empty
white space.

That's because the editor displays those invisible tab control
characters as something they're not: spaces.

Editors display tab characters as "indent to next tab stop". That's what
they're for, and any editor that doesn't behave that way is buggy.

Tab characters are no more invisible than space characters. How can you
see space characters but not tabs? Why aren't space characters invisible
too? Why do you dislike tabs *specifically* because they are invisible,
but like invisible spaces?

If you can't see spaces then that's your problem. I can see (identify)
spaces (at least at the beginning of a line).

2. I never had problems with spaces but plenty with tabs

What problems have you had with tabs that aren't related to buggy
applications or users that mix tabs and spaces?

Fortunately I don't remember every incident when I stumbled about
something weird behaving or looking. One thing I do remember is reading
python source code (not my own) with a pager. The source code was badly
indented. The pager was not "buggy".

Given the constraints of the typical pager one-line display, and the
tendency of pagers I've seen to arbitrarily drop leading whitespace *of
any sort* from the start of lines, I'd like to know how you could tell
the indentation was wrong.

It was obvious because the blocks didn't make sense.

The problem with tabs is that they're interpreted: by Python and by
the editor or pager to display them. Spaces are just spaces.

Thorsten

[Thorsten Kampe]

* Steven D'Aprano (Mon, 31 Dec 2007 00:05:15 -0000)

On Sun, 30 Dec 2007 20:41:09 +0000, Thorsten Kampe wrote:

Anyway: the consequence of your well done argumentation is that
someone editing Python code has to use a specialised editor to prevent
screwing up tab indented code - and that's bad.

You just need to use an editor that inserts tab characters when the tab
key is pressed, just like you use an editor that inserts s characters
when the s key is pressed. If people didn't insist on using spaces where
tabs are called for, there would be no problem, and you wouldn't need a
specialized editor to prevent screwing up space-indented code.

You completely miss the point. Ben (and me answering him) was talking
about tab indented code that gets screwed up by spaces by people who
can't see the tabs. Read Ben's article again.

Thorsten

[Steven D'Aprano]

On Mon, 31 Dec 2007 12:36:11 +1100, Ben Finney wrote:

Steven D'Aprano <st***@REMOVE-THIS-cybersource.com.auwrites:

>On Sun, 30 Dec 2007 20:41:09 +0000, Thorsten Kampe wrote:

Anyway: the consequence of your well done argumentation is that
someone editing Python code has to use a specialised editor to
prevent screwing up tab indented code - and that's bad.

You just need to use an editor that inserts tab characters when the tab
key is pressed, just like you use an editor that inserts s characters
when the s key is pressed.

No, that's not all you need to do. You also need to keep your code away
from the majority of programmers, who use their default editor in its
default settings

I question that. On my system at least (Fedora 7), here are the default
settings on the editors I have available:

vi default is tab character
emacs default is tab character
gedit default is tab character
nano default is tab character
joe default is tab character
kedit always uses tab character
kwrite default is tab character
kate default is tab character
scribes default is tab character
eclipse default is tab character

With every Linux distro being slightly different, your mileage may vary,
but with not even a single editor on my system defaulting to spaces, I
hope you can excuse my skepticism.

And if you extend your view to the 90% of the computing world that
doesn't use a Unix-like operating system, we can consider:

VisualStudio default is tab character
Epsilon default is tab character
Notepad always uses tab character
Wordpad always uses tab character

No doubt there are a hundred other Windows text editors, but I'm not
familiar with them. Nor am I familiar with OS X based text editors,
although back in the 1990s Apple Mac text editors invariably inserted a
tab when you pressed the tab key.

and who expect that horizontal whitespace is produced
by the U+0020 space character (even if they don't know the specifics of
the character coding).

Saying that the tabs-only argument and the spaces-only argument are of
equal value is philosophically true, but practically worthless. They're
of equal value *only* in isolated environments where you can control the
expectations of *every* programmer who will *ever* edit the file.

Ah, and now we're getting somewhere! It's not so much that tabs are
intrinsically harmful (as people like Thorsten keep insisting), but that
in a world supposedly dominated by people who indent with spaces, using
tabs might lead to inconsiderate programmers ignoring your project's
coding standards and inserting spaces into your code base.

Yes, I can see that is a problem. I believe it is best solved by refusing
contributions from such inconsiderate programmers. After all, if they're
going to ignore your project's code standards in one aspect, they're
invariably going to ignore others as well.

Ben, I'm surprised that you of all people should take such a pragmatic
view that "tabs are bad because the majority use spaces". By that
reasoning, you should be driving a SUV (much safer than riding a bike!),
sending HTML-only emails written in Outlook (with Word as your editor
naturally) and publishing data solely in proprietary binary formats
like .doc. Everybody else does it, why buck the trend?

There's a very good reason to buck the trend whenever practical: tabs
have the considerable benefit that they decouple the presentation of the
code from the structure of the code.

When you use tabs to indent code, the reader can place their tab stops
where ever they wish, according to their own needs and preferences: every
eight spaces, or four, or three, or twenty-seven spaces if they want. One
tab means one indent level (structure), and the width of that indent
(presentation) is up to the reader.

But when you use spaces, you are essentially forcing your presentation
onto all your readers, whatever their wishes. Sure, some editors let you
re-indent code at the press of a button, and some of them might even get
it right more often than not -- but for Python at least, if you want to
contribute code back to the project, you can't afford to do that. You're
stuck using whatever presentation the project manager chooses.

Using spaces is fundamentally broken because it turns a structural single
level of indentation into a presentational four spaces -- or eight, or
two, or five, whatever the project's coding standard insists on.

To form an indentation policy based only on hypothetical
fully-controlled isolated environments is foolish, to say the least.

Just say I'm tilting at windmills.

--
Steven

[Torsten Bronger]

Hallöchen!

Steven D'Aprano writes:

[...]

Ah, and now we're getting somewhere! It's not so much that tabs
are intrinsically harmful (as people like Thorsten keep
insisting), but that in a world supposedly dominated by people who
indent with spaces, using tabs might lead to inconsiderate
programmers ignoring your project's coding standards and inserting
spaces into your code base.

Yes, I can see that is a problem. I believe it is best solved by
refusing contributions from such inconsiderate programmers. After
all, if they're going to ignore your project's code standards in
one aspect, they're invariably going to ignore others as well.

No, you cannot have both tabs and spaces. The whole community must
settle on a single method. I cannot adjust my editor's settings to
the respective SVN tree I'm looking at, nor can I incorporate other
project's code into mine if the indentation method is not the same.

Of course, there is no intrinsic benefit from spaces but it is the
method that has won.

Tschö,
Torsten.

--
Torsten Bronger, aquisgrana, europa vetus
Jabber ID: br*****@jabber.org
(See http://ime.webhop.org for further contact info.)

[Torsten Bronger]

Hallöchen!

Ben Finney writes:

Steven D'Aprano <st***@REMOVE-THIS-cybersource.com.auwrites:

>[...]

There's a very good reason to buck the trend whenever practical:
tabs have the considerable benefit that they decouple the
presentation of the code from the structure of the code.

Huh? I can only interpret this to mean that you think it's a good
thing for a text file one is *directly editing* to be rendered in
such a way that one cannot tell quite what one is really editing.

No. It's more like the old battle visual vs. semantic markup in
markup languages. Both markup is unambiguous. After all, the width
of a tab is nowhere defined. It really is a matter of the editor's
settings. I, for example, dislike too wide indenting. I use four
columns in Python and two in Delphi. However, there are Python
projects using eight spaces for each indentation level.

If all Python code used tabs, eveybody could use their own
preferences, for both reading and writing code, and interoperability
would be maintained nevertheless.

Tschö,
Torsten.

--
Torsten Bronger, aquisgrana, europa vetus
Jabber ID: br*****@jabber.org
(See http://ime.webhop.org for further contact info.)

[Torsten Bronger]

Hallöchen!

Ben Finney writes:

Torsten Bronger <br*****@physik.rwth-aachen.dewrites:

>[...] the width of a tab is nowhere defined. It really is a
matter of the editor's settings.

RFC 678 "Standard File Formats"
<URL:http://www.ietf.org/rfc/rfc678.txt>:

Horizontal Tab <HT>

[...]

As far as I can see, this excerpt of a net standard has been neither
normative nor influential on the behaviour of text editors.

>I, for example, dislike too wide indenting. I use four columns in
Python and two in Delphi. However, there are Python projects
using eight spaces for each indentation level.

How many columns to indent source code is an orthogonal question
to how wide an ASCII TAB (U+0009) should be rendered. [...]

I don't know what you want to say with this. Obviousy, is is
impossible to indent four columns with 8-columns tabs. Anyway, my
sentence was supposed just to lead to the following:

>If all Python code used tabs, everybody could use their own
preferences, for both reading and writing code, and
interoperability would be maintained nevertheless.

Interoperability isn't the only criterion though. On the contrary,
source code is primarily for reading by programmers, and only
incidentally for reading by the compiler.

Well, I, the programmer, want code snippets from different versions
fit together as seemlessly as possible, and I want to use my editor
settings for every piece of Python code that I load into it.

Tschö,
Torsten.

--
Torsten Bronger, aquisgrana, europa vetus
Jabber ID: br*****@jabber.org
(See http://ime.webhop.org for further contact info.)

[Torsten Bronger]

Hallöchen!

Ben Finney writes:

Torsten Bronger <br*****@physik.rwth-aachen.dewrites:

>[...] the width of a tab is nowhere defined. It really is a
matter of the editor's settings.

RFC 678 "Standard File Formats"
<URL:http://www.ietf.org/rfc/rfc678.txt>:

Horizontal Tab <HT>

[...]

As far as I can see, this excerpt of a net standard has been neither
normative nor influential on the behaviour of text editors.

>I, for example, dislike too wide indenting. I use four columns in
Python and two in Delphi. However, there are Python projects
using eight spaces for each indentation level.

How many columns to indent source code is an orthogonal question
to how wide an ASCII TAB (U+0009) should be rendered. [...]

I don't know what you want to say with this. Obviousy, it is
impossible to indent four columns with 8-columns tabs. Anyway, my
sentence was supposed just to lead to the following:

>If all Python code used tabs, everybody could use their own
preferences, for both reading and writing code, and
interoperability would be maintained nevertheless.

Interoperability isn't the only criterion though. On the contrary,
source code is primarily for reading by programmers, and only
incidentally for reading by the compiler.

Well, I, the programmer, want code snippets from different origins
fit together as seemlessly as possible, and I want to use my editor
settings for every piece of Python code that I load into it.

Tschö,
Torsten.

--
Torsten Bronger, aquisgrana, europa vetus
Jabber ID: br*****@jabber.org
(See http://ime.webhop.org for further contact info.)

[Ben Finney]

Steven D'Aprano <st****@REMOVE.THIS.cybersource.com.auwrites:

On Wed, 02 Jan 2008 15:17:54 +1100, Ben Finney wrote:

Torsten Bronger <br*****@physik.rwth-aachen.dewrites:

[...] the width of a tab is nowhere defined. It really is a matter of
the editor's settings.

RFC 678 "Standard File Formats"
<URL:http://www.ietf.org/rfc/rfc678.txt>:

Dated 19 December 1974.

So? The point is made: it's not true to say "the width of a tab is
nowhere defined". Everything I can find that is in any way close to a
"standard" defines the canonical width of an ASCII TAB as being eight
columns.

At least that one also acknowledges what we all know: that (even in
those times) actually enforcing that canonical width is difficult.

I think it tells a lot about the spaces-only argument that it is
based on the state of the art thirty years ago

I think it says a lot about this thread that you've devolved to taking
a side point I raise merely to disprove a distracting fallacy, and
claim that my core argument "is based on" it.

It says, at least, that it's time for me to stop contributing to this
thread, as it won't improve from here. My argument is made, earlier in
this thread, utterly unrelated to this "width of a TAB" point, and it
remains whether it convinces anyone who contributed or not.

--
\ "Don't worry about people stealing your ideas. If your ideas |
`\ are any good, you'll have to ram them down people's throats." |
_o__) -- Howard Aiken |
Ben Finney