Well, an exclusive indent char might be nice, but TAB is very easy for almost
everyone to enter by default already. Used the way @Tutbadut and @Araq were
discussing only at the beginning of lines ('^TAB*[^TAB]' in Regex-ese) it could
function that way. It's true that a brand new character might side-step the
diverse ways to configure the amount of rendered blank space per tab, but at
the non-zero cost of mandating unicode.
While source code "in the large" is not tabular data, in a
leading-whitespace-for-block-structure language like Python or Nim, that part
of the text has "regimented spacing concerns" much like a table. TAB characters
of any fixed width are actually less useful for tables than the old early 20th
century mechanical typewriter tab-stops that inspired the TAB character.
Tab-stops were totally configurable - first at 4, next at 8, next at 10 or 20,
etc. That flexibility was largely lost in the transition to ASCII-oriented
software. { You think _one_ conversion ratio is a pain in the ass...try
_dozens_! ;-) }
Anyway, detecting the very first '^[some-kinda-white]' and mandating whole-file
consistency afterward seems "not so hard", especially if you allow comment-only
lines as candidate leading white-space determiners. In spite of not being so
hard, most text editors punt on it, only doing line-global/file-global type
transformations leading to Araq's observations. It would be a really easy CLI
text filter to do leading-space only..probably less work than reading this
whole thread and also of value to non-`.nim` files. Probably exists already,
too. Using hard tab for leading indent only and letting divergent users adjust
as they like seems philosophically much like Nim's style insensitivity, only
with far more common environmental support for tunable rendering.
The only real problems are defaults of 8-spaces per TAB being 4x more than what
Nim people are used to and diversity/unavailability of TAB size setting.
Combined that creates trouble for the many to please the few. I'm pretty sure
the diversity/unavailability of adjustment/having to tell Python TAB-size
conversion complexity was what led to Guido's regret, mixed in with some
Wadler's Law can't-believe-we're-arguing-about-it.
Anyway, just food for thought. I'm not really advocating anything.
