Tab indentions on different platforms?

[Ben Finney]

Steven D'Aprano <steve at REMOVE-THIS-cybersource.com.au> writes:

> On Mon, 31 Dec 2007 12:36:11 +1100, Ben Finney wrote:
> 
> > Steven D'Aprano <steve at REMOVE-THIS-cybersource.com.au> writes:
> > 
> >> 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 remind you that the earlier context of this "default settings" was a
discussion of how text editors *render* horizontal whitespace
characters: that the majority of environments make no visual
distinction between a U+0009 TAB and an equivalent sequence of U+0020
SPC characters.

> I question that. On my system at least (Fedora 7), here are the
> default settings on the editors I have available:
> 
> [most editors default to inserting a U+0009 TAB when the Tab key is
> pressed]

Yes. I never raised the point about what happens when the Tab key is
pressed.

My point about default settings, rather, is that most editing
environments in their default settings will not visually distinguish
an *existing* TAB from a SPC sequence.

Instead of talking about *what happens* when the Tab key is pressed,
my argument was rather that many files will be edited such that the
Tab key is *not* pressed for indentation, because:

> > [users of such environments are led to] 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.

I disagree that such a programmer would be "inconsiderate" by merely
following the least-surprising interpretation of what they see in
front of them.

> 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.

Again, your argument rests on the fantasy of being able to exert
control over those who would edit those files.

> Ben, I'm surprised that you of all people should take such a
> pragmatic view that "tabs are bad because the majority use spaces".

I'm sorry if you've been led to believe I'm averse to pragmatism; I'm
very much enamoured of it. What I'm averse to is *false* pragmatism
that turns out merely to be delusion or false economy.

> 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.

I don't consider that a good thing at all. Editing a text file is an
occasion when it is *essential* to know exactly what changes one is
making, at a character-by-character level.

> 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.

That's fine if *all* they do is read the code. I'm coding for those
who will read the code with a view to *editing* it as well. For such a
reader, I want the visual rendering of the file to show the character
structure of the file as obviously as possible, to enable them to edit
it with the least potential for astonishment.

> But when you use spaces, you are essentially forcing your
> presentation onto all your readers, whatever their wishes.

This is an argument against, for example, forcing an HTML document to
render the same way on multiple devices. That argument leads,
correctly in my view, to the conclusion that presentation should be
decoupled from structure -- for documents that are rendered from a
source form to a presentation form that is significantly different.

But a programming source file is different from an HTML document in
that the presentation *must not* be decoupled from the character
structure, because the reader expects to be able to *edit the file
directly*. What they see should directly reflect the character
structure of the text file, because it is characters they will be
manipulating.

-- 
 \          "The best way to get information on Usenet is not to ask a |
  `\            question, but to post the wrong information."  -- Aahz |
_o__)                                                                  |
Ben Finney