peter@ficc.uu.net (Peter da Silva) (12/10/88)
In article <80360@sun.uucp>, lm@snafu.Sun.COM (Larry McVoy) writes: > In article <9149@ihlpb.ATT.COM> gregg@ihlpb.ATT.COM (Wonderly) writes: > >One of the most frustrating things for me is that so many people insist > >on using a mixture of spaces and tabs for indentation. It seems obvious > >that editors like vi(1) have commands like ":set tabs=4 sw=4" for some > >reason! > sw=4 is cool. ts=4 is not. What happens when I do "lpr $.c" after > some boy genius has missused the ts=4 feature? Yeah, I know about expand, > but that is a hack and screws up other code. The idea that I think the original poster is getting at is that if you set your indent to a single tabstop you can dynamically change the indent level at your leisure. If I like 4-char indents, I can edit it that way. If you like 8 char indents, you can edit it that way. If the code is nested too deeply, it can be much more pleasant to work with after setting "ts" and "sw" to 1 or 2... but it will still print pretty. If I find a program that's got indentations less than a tabstop, it goes through 'cb' first thing... and to hell with the pretty comments. -- Peter da Silva `-_-' Ferranti International Controls Corporation "Have you hugged U your wolf today?" uunet.uu.net!ficc!peter Disclaimer: I accept full responsibility for my typos. peter@ficc.uu.net
connet@sal24.usc.edu (David Connet) (12/10/88)
In article <80360@sun.uucp> lm@sun.UUCP (Larry McVoy) writes: >sw=4 is cool. ts=4 is not. What happens when I do "lpr $.c" after >some boy genius has missused the ts=4 feature? Yeah, I know about expand, >but that is a hack and screws up other code. You use a filter such as 'pr' and use '-e4'. Simple.
robert@rabbit1.UUCP (Robert Oliver) (12/16/88)
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!robertgordon@sneaky.TANDY.COM (Gordon Burditt) (12/19/88)
In article <755@rabbit1.UUCP> robert@rabbit1.UUCP (Robert Oliver) writes: >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. Yecch! ... >PROPOSITIONS > II. STORING TABS IN FILES ISN'T USEFUL ... >SUPPORTING ARGUMENTS ... > 2. TRANMISSION SAVINGS IS MINIMAL ... > 6. ONLY MINIMAL SPACE SAVINGS WHEN TABS ARE STORED ... I don't care much about transmission savings or file space savings. I want tabs in files for editing purposes. If it is necessary to add or delete a conditional or loop, I want to be able to add or delete 1 tab stop, not to have to count spaces. # define BAR 72 /* Cost of a BAR as a percentage of a BARF */ # define FOOM 02000 /* Bit in dp->missile.control for self-destruct */ ^ ^ tabs If it is necessary for me to change the value of BAR from 72 to 2, I do NOT want the comment to move. With a tab there, it won't. With spaces there, it will. Granted, there are cases where running over a tab stop will cause movement where I don't want it, but even these cases are usually easier to fix with tabs there than spaces. Gordon L. Burditt ...!texbell!sneaky!gordon
robert@rabbit1.UUCP (Robert Oliver) (12/23/88)
In article <5516@sneaky.TANDY.COM>, gordon@sneaky.TANDY.COM (Gordon Burditt) writes: > In article <755@rabbit1.UUCP> robert@rabbit1.UUCP (Robert Oliver) writes: > >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. > I don't care much about transmission savings or file space savings. > I want tabs in files for editing purposes. If it is necessary to add > or delete a conditional or loop, I want to be able to add or delete > 1 tab stop, not to have to count spaces. > > # define BAR 72 /* Cost of a BAR as a percentage of a BARF */ > # define FOOM 02000 /* Bit in dp->missile.control for self-destruct */ > ^ ^ tabs > If it is necessary for me to change the value of BAR from 72 to 2, > I do NOT want the comment to move. With a tab there, it won't. With > spaces there, it will. Granted, there are cases where running over a > tab stop will cause movement where I don't want it, but even these cases > are usually easier to fix with tabs there than spaces. > Depends on how you perform the edit, and (referring back to my original posting) how well your editor supports the spaces rather than tabs concept. Your methods of thinking are still oriented towards the stored tab concept, and the editors you use were designed for that. Even so, in your example I see no reason why editing 72 to 2 should cause a problem. In "vi" terms, don't use "cw2<esc>"; that will cause the unwanted shift. Instead, simply use "R2 <esc>". Granted, in other examples, extra spaces will be needed, and might annoy you. But that's still a limitation of vi; not an inherent defect in my proposal to eliminate stored tabs. What if vi could handle all white-space like a tab? Then a new form of the cw command would do just what you want. An editor designed for the current Unix tab conventions shouldn't be used to judge my proposed tab conventions. Concerning your comment about adding or deleing a conditional or a loop, again, a non-stored-tab editor should do just fine. Using the example of inserting a loop, and thus needing to shift a block of text to the right, and using vi (only becuase I'm most familiar with it), here's a comparrison: VI -- range insert tab at beginning of line 'a,.s/^/<tab>/ New Coke VI version 1 -- range insert of tab at beginning of line 'a,.s/^/<tab>/ Yes--that might work! The editor just converts it to the correct number of spaces. New Coke VI version 2 -- range move of all text in line to column 8 'a,.s/^.*$/#8&/ (or some such syntax) Deleting a loop construct could work the same way. And the possibilities are endless. Non-tab-storing editors could have all sorts of abilities I haven't i thought of. The last example above is my favorite. You wouldn't believe how useful column edits are for lining comments up. Commands like "move all text beyond column 50 which matches the pattern /\*.* to column 55" is great. And watching it happen to every line on a screen is statisfying. Comments that got shifted left or right when you globally changed two variable names suddenly line up! Some move left; some move right; some stay the same. I should film that and set it to Mozart some time. But I digress. And I don't want to discourage comment! By all means, keep at it. Hack away at my proposal. I must admit that your posting gave me pause. And *I* had to shift out of the stored-tabs concept I'm currently used to in Unix and relate back to other non-Unix editors to reorient myself. I hadn't covered editing ease thoroughly in my original posting; I appear to have concentrated mostly on input mode rather than editing existing documents. I'm considering this further and want to see if I can think of some way in which editing a file with stored tabs is easier than one with only spaces, even with the proper editor for the given universe. Any more suggestions, anyone? One thought that occurred to me is that conversion of tabs to spaces on input causes some information to be lost when the file is saved. It's hard to quantify, since only slightly less is lost in the stored tabs universe. There, though you retain tab placement information, you loose the tab width information. Which means you can loose correct alignment with non-tabbed but space-aligned columns (my main argument against stored tabs). Did anyone ever expect to read entire articles on one ASCII control character? -- Robert Oliver Rabbit Software Corp. (215) 647-0440 7 Great Valley Parkway East ...!{cbmvax,cuuxb}!hutch!robert Malvern, PA 19355 ...!psuvax!burdvax!hutch!robert