Chris Angelico <ros...@gmail.com>:
> On Mon, Mar 20, 2017 at 6:37 PM, Marko Rauhamaa <ma...@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
--
https://mail.python.org/mailman/listinfo/python-list
