Who are the "spacists"?

Marko Rauhamaa marko at pacujo.net
Mon Mar 20 05:56:13 EDT 2017


Chris Angelico <rosuav at gmail.com>:

> On Mon, Mar 20, 2017 at 6:37 PM, Marko Rauhamaa <marko at pacujo.net> wrote:
>> The tools I mentioned honor the traditional tab stop columns:
>>
>>     1, 9, 17, 25, 33, 41, 49, 57, 65, 73
>
> (Point of clarity: "whitespace" is a general term that covers U+0020
> SPACE, U+0009 CHARACTER TABULATION, U+000A LINE FEED, U+2008
> PUNCTUATION SPACE, and others. You're talking about mixing *spaces*
> and tabs.)
>
> That means that you were depending, in your source file, on something
> that isn't actually part of the character's definition.

Those tab stops are a 40-year-old de-facto UNIX standard.

> You're depending on "horizontal tab" meaning those exact tab stops.

Not me. All terminal emulators, editors, text utils etc honor the
convention out of the box. No wonder then that C source code files have
consecutive lines indented randomly:

   HT
   SPC HT
   SPC SPC SPC SPC HT

etc. The tools show no visible difference between those variants, so you
can't blame the developers for being inconsistent.

> If you want those semantics, you should use spaces -

That is precisely what we have done: HT is banished (except in
Makefiles, but we have banished Makefiles as well...).

> or better still, *change your needs* and don't align things like that.
> In far too many fonts, this simply won't work.

You must use fixed-width fonts even in the absense of HT's. Try RFC 793,
for example:

   TCP Header Format

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Source Port          |       Destination Port        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Sequence Number                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Acknowledgment Number                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Data |           |U|A|P|R|S|F|                               |
   | Offset| Reserved  |R|C|S|S|Y|I|            Window             |
   |       |           |G|K|H|T|N|N|                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Checksum            |         Urgent Pointer        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Options                    |    Padding    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             data                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Those kinds of ASCII graphics diagrams are commonplace in source code
comments.

> (It was only from context that I figured out that that's what you were
> even aiming for. It didn't work in my email.)

When participating in technical discussions, I strongly recommend using
a fixed-width font. For example:

   =====  =====  =======
     A      B    A and B
   =====  =====  =======
   False  False  False
   True   False  False
   False  True   False
   True   True   True
   =====  =====  =======

   <URL: https://www.python.org/dev/peps/pep-0012/>

>> The presence of a HT code point in a plain text file is not a
>> semantic marker for indentation. It is a silly, traditional
>> compression scheme for whitespace.
>
> Only if you truly expect and assume that. Can you show me a standards
> document that says "the meaning of this byte/character value is this
> sequence of this other byte/character"?

I already mentioned three examples: lpr, cat on a terminal and Firefox.
Ultimately, it's the terminals that dictate the de-facto standard.

I bet some terminal emulators support ANSI escape sequences to set the
tab stops to arbitrary columns, but nobody uses that type-writer-era
mechanism.

>> If you ever had to review C source code pull requests where tabs and
>> spaces alternate randomly...
>
> Yes, and if you've ever had to review source code pull requests where
> the letters "q" and "e" were used interchangeably, you'd also be
> appalled.

Huh? I'm talking about a real issue. I'm surprised you haven't run into
it.

> The different kinds of whitespace have different semantic meanings,

Only in your head (and Makefiles).


Marko



More information about the Python-list mailing list