Latest indent request

[Robert Oliver]

After working on many varied computers, operating systems, and terminals,
it's my opinion that tabs should not be stored in files and expanded
upon output.

Tabs, which applied well to typewriters, were originally intended as a
means of making INPUT (i.e., TYPING) easier.  Hitting the tab key to move
over to a predefined point is still a vaild concept even with computers.
But there is no good reason, and several good reasons against, storing tabs
in files as characters to be expanded upon output.

I'm not sure who we have to thank for the problems inherent in the practice 
of storing tabs in files and expanding them upon output, though I suspect
it was DEC.  I can even believe it sounded like a good idea at the time.
But the practice causes more grief than it's worth, and should be stopped.
I certainly hope that future creators of applications and operating systems
read this, agree, and take heed, but I don't suspect it will happen.  

If you're interested in the details of my argument, read on.   From the
length of the argument, you can tell that it's a sore point with me.
But from the constantly recurring postings regarding "vi" and tabs, I
can tell that it's a real problem.

===============================================================================

My argument is based on the following main propositions, supported by the
points that follow.

PROPOSITIONS

    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


SUPPORTING ARGUMENTS
  1.  THE DEFACTO INDUSTRY TAB STANDARD ISN'T THAT USEFUL
      The industry defacto standard (set by DEC, is my guess) is a tab stop 
      hard-wired every 8 spaces.  For indenting code, this is generally too 
      big.  For creating tables, it's a bit inflexible.

  2.  TRANMISSION SAVINGS IS MINIMAL
      Even if the tab stops used by the terminal are acceptible or alterable, 
      how useful is it anyway?  At best this serves as a form of data
      compression.  Maximum transmission savings is minimal, because cursor 
      addressing can generally be used to skip columns with only 3 more 
      characters than a tab.  Printers are generally slow devices anyway,
      so transmission savings aren't realized.
  
  3.  DUE TO LACK OF A REAL STANDARD, SOFTWARE COMPLEXITY INCREASES
      Since all terminals don't support the same tabbing or commands, 
      another level of software complexity is added.  
      
  4.  WHERE THE SOFTWARE OR HARDWARE SUPPORT IS INSUFFICIENT, ERRORS OCCUR
      OR ANY TRANSMISSION SAVINGS ARE LOST
      Since some terminals don't support tabbing at all (or not in a fashion 
      that the software understands), the software must be written to handle 
      these cases by expanding tabs before transmission anyway.  This
      eliminates any savings.  And if the software doesn't do this, the
      tabs don't expand properly at the terminal.

  5.  THE CONCEPT OF TAB STOPS DOESN'T MESH WITH FLEXIBLE COMPUTER USE
      The rigid typewriter-originated scheme of tab stops doesn't 
      apply well in the world of computers.  Take the following COMMON
      example.

        You have two versions of a source file that you want to compare.
        The file contains tabs.  But, since the rigid every-n-char model
        isn't sufficient for much of anything, there are other lines
        that have spaces in them to line things up on no-tab columns.
  
        Your diff output, however, prepends each line it outputs with
        "< " or "> ", thus shifting the line over two spaces.  Note that
        the rigid tabs don't get shifted over two spaces.  BUT, lines with
        spaces in them DO get shifted over two spaces.  SO, things don't
        line up any more in the diff output.  The lines with spaces are now
	two columns shifted from the lines with tabs.

      The only way around this is to EXPAND TABS BEFORE TRANSMISSION.
      This eliminates any transmission savings.  And if the expansion 
      is done at the application level, then EVERY application must do it.  
      If it's done at a lower (tty driver) level (so that every application 
      is affected), then you're adding a lot of complexity to the driver.  

      Note that Unix DOES try to deal with tabs in the driver.  But doesn't
      even attempt to deal with the "shift" problem, probably because it 
      can't really be certain what was intended when the tab was put in the
      file.

  6.  ONLY MINIMAL SPACE SAVINGS WHEN TABS ARE STORED
      As with transmission savings, storing tabs in a file is only a a 
      restricted form of compression.  And with the cost of disk space having 
      gone through the floor many years ago (and about to hit magma what with 
      optical disks and such), who cares?  And memory is still LOTS less 
      expensive than it was when the tab business came into common use on PDPs.

  7.  NO FLEXIBILITY IS GAINED
      Some might argue that a file with tabs in it allows different
      people to set their tabs to their own preferences, thus allowing
      two different people to view the same file in their own way.  This
      is a nifty idea, but even if it were really that useful, it doesn't
      work in reality.  As mentioned in the "diff" example, the "shift"
      problem arises.  Lines that use spaces to line things up won't be 
      shifted relative to lines that use tabs.  And the very definition of 
      tabs means that they are not flexible enough for all cases.  The 
      only way to make them flexible enought would be to set a tab in every 
      (or every other) column.  But then you might as well not use tabs.

      Even if the ability for different users to view using different
      tab settings worked without the shift problem, and even if the complexity
      of the software and hardware didn't concern you, the real benefit
      is not great.

CONCLUSION

The best editing envrionment I have encountered allowed the setting of
tab-stops at arbitrary points on a line.  It also allowed me to press
the tab key to advance to the next stop on the line.  BUT IT DID THIS
BY INSERTING THE PROPER NUMBER OF SPACES INTO THE FILE.  Furthermore,
you could turn this off, and let the tab be entered, if you really wanted
to.  The operating system treated a tab character in a file treated just 
as any other control character that doesn't normally have a meaning, and 
passed it along.  Thus, you could really use hardware tabs if you were
hell bent on doing so.

Sure, allow the tab key to be expanded on input, depending upon the
application.  BUT DO NOTHING ELSE WITH IT.  Thank you, and good night.


(Quick, where's my asbestos?)
-- 

Robert Oliver			
Rabbit Software Corp.		(215) 647-0440
7 Great Valley Parkway East     ...!{cbmvax,cuuxb}!hutch!robert
Malvern, PA  19355		...!psuvax!burdvax!hutch!robert