Who are the "spacists"?

[Chris Angelico]

On Mon, Mar 20, 2017 at 8:56 PM, Marko Rauhamaa <marko at pacujo.net> wrote:
> 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.

Actually you can, for the same reason that you expect programmers to
use ASCII Latin to write language keywords, not other symbols that
happen to look identical.

>> 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.
> [chomp examples]

Yes, there are good reasons for using monospaced fonts for certain
types of documents. But if those documents have been created
correctly, they won't be mixing tabs and spaces to achieve that
alignment - they'll be using spaces exclusively.

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

Do they actually document that its meaning is strictly as you
describe? On all of my terminals, a tab is *NOT* the same thing as X
spaces - for example, highlighting with the mouse will grab the entire
tab as a single character, and will copy it to the clipboard as a
character. Also, check out 'man tabs'. It's trivially easy to tell the
terminal to use a different set of tab stops, and catting a file will
look different. Notice that I didn't say "reconfigure cat". It's not
cat that does this - it's only the terminal, and I suspect that every
modern terminal on every POSIX system supports it (since the 'tabs'
command is itself part of POSIX). What 'lpr' does with tabs I don't
know, because paper is an archaic data transmission format that I use
only when absolutely necessary (such as when sending information off
to the gummint). Firefox... what's the betting that it can be
configured too, maybe with CSS?

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

Probably not. Most people would use the tabs(1) command instead.

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

Maybe I have, and just rejected the PR out of hand. It certainly isn't
something that I am forced to wrestle with. Every PR that I have
accepted has been internally consistent (either all tabs or all
spaces).

>> The different kinds of whitespace have different semantic meanings,
>
> Only in your head (and Makefiles).

And in the Unicode specifications, and in a lot of other people's
heads. But you're welcome to reject all that too.

ChrisA