in reply to Re: The classical TAB issue
in thread The classical TAB issue

In theory, one could use tabs to indicate indentation of the block and use spaces to indicate a line continuation or to make things vertically aesthetic:

sub foo { <tab>while (<FOO>) { <tab><tab>chop; <tab><tab> /^ \s* (\w+) \s* = \s* " (.*) " $/x <tab><tab>or /^ \s* (\w+) \s* = \s* (.*) $/x <tab><tab>or die "Malformed line $. in FOO"; <tab>} }

It is unambiguous from the tabs that the first // is at the same block level as its surrounding lines. Unambigous, at least, to a machine or to somebody with visible tabs and/or spaces.

That said, I don't do this, and I've never seen anybody that did. (But I use pico and I don't have many friends. (Draw your own conclusions there.)) And if not everybody follows the convention, then you can't rely on the system.

FWIW, I have had to work with code indented twice around the screen before the inking characters, and had I been using an editor that would shorten tabs, I'd have still ended up with one in ten lines having 160 leading spaces. While K&R and Linus probably overgeneralized with the three-indent rule, I've yet to see any code whose biggest flaw was the characters it used for spacing.

While indent and perltidy are marvelous tools, we also need "unindent" and "perluntidy". Each would take (1) the original source before you got stuck with it, (2) the tidied source, and (3) the tidied source plus your fixes, and spit out (4) the fixed source in the style of the original.