Path: utzoo!attcan!uunet!cbmvax!hutch!rabbit1!robert From: robert@rabbit1.UUCP (Robert Oliver) Newsgroups: comp.unix.questions Subject: Re: Latest indent request Summary: Stored tabs considered bad (Long, but a quick intro for the busy) Message-ID: <755@rabbit1.UUCP> Date: 16 Dec 88 02:23:19 GMT References: <9125@rpp386.Dallas.TX.US> <9149@ihlpb.ATT.COM> <80360@sun.uucp> <2414@ficc.uu.net> Organization: Rabbit Software Corp., Malvern PA Lines: 137 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