tanner@ki4pv.uucp (Dr. T. Andrews) (12/18/88)
In <755@rabbit1.UUCP>, several propositions are made, to wit:
) I. HARDWARE EXPANSION OF TABS DURING OUTPUT ISN'T USEFUL
) II. STORING TABS IN FILES ISN'T USEFUL
) III. SUPPORT OF OF THE ABOVE INCREASES HARDWARE AND SOFTWARE COMPLEXITY
) AND IS THEREFORE COSTLY AND ERRORPRONE
) IV. TABS SHOULD BE EXPANDED ON INPUT IF DESIRED BY THE USER &
APPLICATION
The first point sounds reasonable to me, when I am hooked up on a
19.2K hard-wired terminal. When I am dialed to a computer, I have
often appreciated the savings engendered by tabs on output. What
more can I say than that for documents with lots of white-space,
I get eight times the output speed for the non-information-bearing
portion of the text?
The second point is bolstered by the assertion that disk storage is
becoming cheaper. Consider, however, storage of C code. The lines
may have more print positions filled by white-space than by actual
compilable code. Something like "++blunge.gork" indented three
tabs either requires 24 spaces or 3 tabs in front of 14 characters.
Sure, disk space is cheaper. Does that mean that we should double
our use of it for the same information?
Further, consider the case where you want to COMPILE that source
code. Which is faster: ignoring three tabs, or ignoring 24 spaces?
Consider also that you have to read in the spaces or tabs; assuming
the same average I/O cost per character for spaces and tabs (is
read(2) data sensitive?), you have eight times the cost for the space
version.
The third point, software complexity, is granted. You have to check
for '\t' as well as ' ' and '\f' when you decide if a character is
ignorable white space in the compiler. Other applications have
similar added complexity. So hide it: invent a routine iswhite() and
use it: your complexity is mostly hidden.
The fourth argument, "tabs should be expanded on input", is too
religious for me.
Supplied with the above points were some supporting arguments.
) 1. THE DEFACTO INDUSTRY TAB STANDARD ISN'T THAT USEFUL
That's true. A 4-char tab would have probably been better for
source indenting. However, it's not that bad, either, and at
least we all agree to use 8-char tabs.
) 2. TRANMISSION SAVINGS IS MINIMAL
I trust that anyone who has appreciated tab0 mode over a modem will
know how effectively this one is debunked.
) 3. DUE TO LACK OF A REAL STANDARD, SOFTWARE COMPLEXITY INCREASES
But we \fBdo\fP have a real standard. Those 8-char tabs you detested
in point one are a de-facto standard. People use them. I would
venture to say that the 8-char tabs are more of a standard than X3J11
ever will be!
) 4. WHERE THE SOFTWARE OR HARDWARE SUPPORT IS INSUFFICIENT, ERRORS
) OCCUR OR ANY TRANSMISSION SAVINGS ARE LOST
True. Of course, this applies to newlines and other carriage control
as well. Some terminals don't under <ESC>=RC cursor-addressing.
There are things you can do about this.
) 5. THE CONCEPT OF TAB STOPS DOESN'T MESH WITH FLEXIBLE COMPUTER USE
Sure, and we appreciate your example. You want the source code to a
program which tabifies and untabifies? Solves your problem nicely.
) 6. ONLY MINIMAL SPACE SAVINGS WHEN TABS ARE STORED
Sure. Like about 40% around here, based on my observations of
source files. We use lots of indent.
) 7. NO FLEXIBILITY IS GAINED
True. That's the problem with a standard. See 1 and 3.
CONCLUSION
My conclusion is that I appreciate the ability to store tabs in a
file, and to transmit over slow (eg <=2400) modem connections a
single tab character instead of 8 spaces.
I also appreciate the time saved in compiling tabified sources, and
the space saved by keeping my ".c" files tabified.
--
...!bikini.cis.ufl.edu!ki4pv!tanner ...!bpa!cdin-1!cdis-1!ki4pv!tanner
or... {allegra killer gatech!uflorida decvax!ucf-cs}!ki4pv!tanner