Fatal flaw in D design which is holding back widespread adoption

[Nick Sabalausky]

"Walter Bright" <newshound1 at digitalmars.com> wrote in message 
news:houh5g$29cs$1 at digitalmars.com...
> Nick Sabalausky wrote:
>> But really, I don't see why the whole issue hasn't already been made 100% 
>> personal style by a VCS that handles it the same way SVN handles EOLs. If 
>> one person has problems involving another person using a different 
>> indentation system, then at least one of them is doing something very 
>> wrong. Seriously, how is it that this is 2010, we have things like syntax 
>> highlighting as standard featutres in every editor that anyone ever 
>> actually uses...and yet the whole world of programmers still can't 
>> abstract away something as simple as f*cking tab sizes? Bah!
>
>
> It all started in the 80's when someone wrote a text editor that had 
> customizable tab lengths (before then, tabs were 8. End of story.). Things 
> went downhill from there. Since there's no way for an editor to figure out 
> what the tab setting might be for any particular file, the only solution 
> that works is to not use tabs. Thanks to some nameless programmer who 
> ruined it for everyone <g>.

See, I think this is looking at things completely backwards: "...there's no 
way for an editor to figure out what the tab setting might be for any 
particular file...".

Now that Pandora's box is open (or heck, even if it weren't), it makes sense 
to think of tab as meaning "indent" abstractly and *not* "x number of 
spaces". Ie, "Tab setting for a given file" should be viewed as a 
nonsensical concept, as "tab-size" is (or rather SHOULD be considered) 
purely a presentation concept (Granted, mixed-spaces/tabs screw that up, but 
nearly everyone considers mixed spaces/tabs to be evil anyway, and it's not 
as if there's a chance of that genie ever getting back into his bottle). The 
consequence of this approach is that people can set their tabsizes to 
whatever the hell they want, and things will *just work*.

If someone wants their editor to behave as if the tabs are a series of 
x-number spaces, then fine, it can do that and convert back to tabs (ie, 
"indents") upon saving (or the VCS can do it in much the same way SVN and 
FTP can take care of line-endings). In that case it's, in effect, still just 
a UI-only concept.

This way, in all but that absolute weirdest of the weird situations 
(specifically, people and apps that insist on mixing tabs and spaces), 
everyone eats their cake and still has it.

But then some people insist on always using spaces instead of a dedicated 
indent symbol (ie, "tab"), thus destroying indent-size as a user-setting, 
all for absolutely no real benefit to anyone.

And then editors do none of the rather simple things they could do to 
mitigate tab/space mixing. So there too, the problem persists.

And then a tiny handful of people actually go mixing tabs and spaces on a 
regular basis. Totally fucks things up too.

There's absolutely no need whatsoever for any kind of magical "figure out 
the tab-size for a file". Everyone can have everything the way *they* want 
it without screwing up anything for anyone else all by the convention of 
treating tab as *the* "indent" symbol. (Note that this *is* very different 
from the "everyone will get along if they just think like I do" argument 
pattern.)