"Walter Bright" <newshou...@digitalmars.com> wrote in message news:houh5g$29c...@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.)