wcs@skep2.ATT.COM (Bill.Stewart.[ho95c]) (07/05/88)
Someone asked how to get vi to do autoindent using spaces rather than tabs. I'm not sure all of the implications, but :set tabstop=0 will let you do autoindent without tabs. Already tabbed text seems to get treated decently. The vi Bug: The reason I'm crossposting to comp.bugs.misc is that there's a bug in the hardtabs handling that causes vi to dump core. Try :set hardtabs=0 and watch for the floating point exception. -- # Thanks; # Bill Stewart, AT&T Bell Labs 2G218, Holmdel NJ 1-201-949-0705 ihnp4!ho95c!wcs Rnmail: .signature too boring - deleted
jpn@teddy.UUCP (John P. Nelson) (07/08/88)
>I'm not sure all of the implications, but > :set tabstop=0 >will let you do autoindent without tabs. Already tabbed text seems to >get treated decently. At least with BSD versions of "vi", a :set tabstop=0 is IDENTICAL to :set tabstop=8. After setting the tabstop to zero, tabs are 8 long, and a "set all" lists the tabstop variable as having the value 8, not 0. -- john nelson UUCP: {decvax,mit-eddie}!genrad!teddy!jpn smail: jpn@genrad.com
wcs@skep2.ATT.COM (Bill.Stewart.[ho95c]) (07/12/88)
In article <4885@teddy.UUCP> jpn@teddy.UUCP (John P. Nelson) writes: } > Bill Stewart writes: } >> :set tabstop=0 } >>will let you do autoindent without tabs. Already tabbed text seems to } At least with BSD versions of "vi", a :set tabstop=0 is IDENTICAL to } :set tabstop=8. After setting the tabstop to zero, tabs are 8 long, Arrgh, sure enough! I use vi version 3.9 (found in SVR2 and following), but I scrounged up a 3.7 version (4.*BSD, V8, V9, SVR0, etc.) and it did what John claimed. As long as you detab the document first, you can use :set tabstop=99 to make tabstops big enough vi doesn't use them (assuming you don't want to use the TAB key to indent with.) Or you can pipe your file through col -x to zap tabs afterwards. -- # Thanks; #Bill Stewart, AT&T Bell Labs 2G218 Holmdel NJ 201-949-0705 ho95c.att.com!wcs
mitch@Stride.COM (Thomas Mitchell) (07/14/88)
>} :set tabstop=8. After setting the tabstop to zero, tabs are 8 long,
One thing I found was that for many terminals the command to clear
the tabs in termcap and terminfo was missing or wrong. These
were AT&T as well as UCB files. In fact a termcap application
note from a terminal manufacturer had the same error.
The result is that the editor attempts to reset the tabs --
thinks it has, but the terminal still has it wrong. Then the I/O
update routines emit a tab char to be at a specific column but lo
the terminal still has the tab stops set in all the wrong places.
This produces some real junk with FORTRAN and COBOL modes.
(Up on the Soap Box)
In general I hate what most people do with tabs. On a typewriter
a tab is a tab stop (this is cool). In a machine file a tab is
an ASCII character. In the context of input it may be simple to
know what is expected. Later on output it becomes tough to keep
a family of programs tracking on this same intent (not cool).
(Down from the Soap Box)
Thanks for your time,
--
Thomas P. Mitchell (mitch@stride1.Stride.COM)
Phone: (702)322-6868 TWX: 910-395-6073 FAX: (702)322-7975
MicroSage Computer Systems Inc.
Opinions expressed are probably mine. jpn@teddy.UUCP (John P. Nelson) (07/14/88)
In article <832@stride.Stride.COM> mitch@stride.com (Thomas Mitchell) writes: >>} :set tabstop=8. After setting the tabstop to zero, tabs are 8 long, > >One thing I found was that for many terminals the command to clear >the tabs in termcap and terminfo was missing or wrong. While this may be true, it has absolutely nothing to do with the :set tabstop command in vi. This command does not attempt to change the terminal's idea of the tabs: It assumes that the terminal ALWAYS has 8 char tabs (or no tabs at all, if the tty mode is set appropriately). All it does is change the way that vi DISPLAYS tab characters. There IS a vi variable called "hardtabs", which tells vi that the terminal has tabstops other than every 8 characters. This is usually never used, because most OTHER programs don't understand the change in tab width. This option is advisory, though: Vi NEVER attempts to change the tab settings on a terminal, -- john nelson UUCP: {decvax,mit-eddie}!genrad!teddy!jpn smail: jpn@genrad.com
inc@tc.fluke.COM (Gary Benson) (07/15/88)
mitch@Stride.COM (Thomas Mitchell) writes:
"(Up on the Soap Box)
"In general I hate what most people do with tabs. On a typewriter
"a tab is a tab stop (this is cool). In a machine file a tab is
"an ASCII character. In the context of input it may be simple to
"know what is expected. Later on output it becomes tough to keep
"a family of programs tracking on this same intent (not cool).
"(Down from the Soap Box)
(OK, MY turn on the Soap Box!)
I hate the way the information processing industry has handled tabs, too!
They call it a TAB after all, in an attempt to emulate what that little
metal tab on a typewriter did -- stop the carriage at the location the tab
was physically inserted. When ASCII came along the need for a similar
capability must have been recognized, but manufacturers of output devices
and software both looked to their own little situation and never thought to
standardize on the meaning of "Number Nine". Instead what you get is one
manufacturer (or software house) deciding to put tabs every eight spaces or
every five spaces or converting them to a single space or something, totally
ignoring the original concept: the user determines where the tabs are to be
at the time the document is created. Sure it makes things more complicated,
because then the software guy has to include the information somehow as the
document is transmitted and the printer manufacturer has to decide how to
read this information from a file and what to do with it on his machine.
Some desktop publishing software seems to be going the right direction by
including a "ruler" as part of the document. To ever get tabs to make sense
with the new technology, we will probably have to standardize the format and
content and intent of the ruler.
Along the same lines, the new information technology seemed to open a can of
worms regarding Carriage Return, too. It is a similar situation: in a
typewriter, there was no such thing as a "line feed". There was INDEX, a
totally separate function from <CR>. I think (although I'm not sure) that it
was IBM who separated <CR> into it's horizontal and vertical components,
creating a lot of confusion over the meaning of <CR>. Do you know that there
are systems out that require TWO codes to return to the left margin, then
generate the new line (<CR><LF>)? How silly. In trying to simplify matters,
ASCII instead left <CR> and <LF> as related but ambiguously defined ideas.
Now in trying to make some sense of things, we wind up with some of the
wierdest things happening. Just now some colleagues and I were trying to
logon to a remote machine that sends only the horizontal postion part of the
command <CR> without <LF>. We tried two different modem programs, neither
one of which gives the option of correcting this behaviour on our end. So
tomorrow, someone will hand-carry a floppy disk. I guess that's pretty
primitive and time-consuming, but it's a whole lot less frustrating and
time-consuming, and a whole lot more productive, than arguing with the guy
over who's software is "right".
(The Soap Box is once again available...)
--
Gary Benson -_-_-_-_-_-_-_-_-inc@tc.fluke.com_-_-_-_-_-_-_-_-_-_
Publication Services Ensign Benson, Space Cadet, Digital Circus, Sector R
John Fluke Mfg. Co. Inc. _-_-_-_{uw-beaver, sun,microsoft}!fluke!inc-_-_-_-_-