[bug #39943] Add an alternative parsing mode that regards space and tab

[Frank Heckenbach]

Just my 2¢ ...

Paul D. Smith wrote:

> As for your suggestion regarding the term "hard tab", when I wrote that
> message I'd never heard this term.  I'm still not sure why the prefix "hard"
> is added; what is being distinguished by this?  A TAB is a TAB, and there's
> only one TAB character.  There's no such thing as a "soft tab": I don't really
> know what that means.  However, I'm willing to change the message text if
> people think it will be significantly clearer.

"Hard tab" seems uncommon to me, too. Actually there are two tab
characters, horizontal and vertical. Maybe that's the etymological
origin, someone abbreviated horizontal tab to HTAB and someone else
interpreted it as hard tab. Still, where's my soft tab? :)

David Boyce wrote:

> You know what they say about standards and how great it is that
> there's so many? The Python coding standard calls for no use of tabs
> and thus many people who do Python coding have their editors
> configured to turn tabs into spaces. I do, for example.

Our coding standards (C/C++) also avoid tabs, yet I rarely find the
need to turn tabs into spaces. When we write code, we just type
spaces, and when writing Makefile, we put the tabs where needed.
Only if we import some code written with tabs, we might turn them
into spaces, but that's rare, and if so, we prefer to do it
explicitly (possibly together with other kinds of reformatting), not
have the editor do it automatically.

That said, the tab-as-a-meaningful-element does rank rather high on
my list of syntactical misfeatures of any language, so I'm
interested to read about .RECIPEPREFIX (hadn't noticed it before).
Since many of my makefiles already use GNU make specific features,
backward-compatibility wouldn't be a big issue, so I could probably
start using it today. Just wondering (since I hadn't heard about it
before), is this feature tested in practice, or should I expect some
teething problems? And are there any conventions/recommendations for
a good alternative prefix character yet?

PS and somewhat OT, Tim Murphy wrote:

> I think that such snags are truly because there is a bit too much
> freedom. It's like this thing in C:
>
> int i;
> for (i=0; i < 10; fred(), i++);
>     printf("%d",i);
>
> Oh what a tyranny it would be if for() required braces instead of
> allowing you to do one-liners. Sure but it would make a class of
> stupid bugs vanish.

Interestingly, GCC warns about this bug in if-statements
(-Wempty-body), but not in for-loops. Of course for-loops with empty
bodies can be meaningful in C (if fred() has side effects), but if I
do mean this, I prefer to be more explicit and use empty braces for
the body, so I'd also prefer to be warned about this. You might want
to bring it up with the GCC developers (though I fear the choice is
intentional and they won't just change it so easily ...).