patkar@cb.ecn.purdue.edu (The Silent Killer) (06/29/88)
> ==================================================================== > Um Kathy, I want autoindent + NO TABS (for C programs and the like). > ==================================================================== The way I do it is by using the unix utility 'expand' from within 'VI'. I know this does not prevent insertion of tabs, but it at least removes them once you have used the command !<movement command>expand The <movement command> may be (, {, 1G etc. In writing LISP functions, for example, I find the command '!%expand' very useful. Anant Patkar. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ o __________________ ____________________________ / ) | | ___| | | | _| __|_ / | patkar@ecn.purdue.edu ---| o--| ( | `___| | ' '__| ) o/ | patkar@purche.BITNET \_) | | \ | | | `-- | \ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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
clarkm@tekig4.TEK.COM (Clark Morgan) (07/07/88)
In article <177@skep2.ATT.COM> wcs@skep2.UUCP (46323-Bill.Stewart.[ho95c],2G218,x0705,) writes: >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. > Bill, how did you do that? Our version of vi accepts :se ts=0, but silently sets the tabstop back to 8. In other words, I can't get there from here. We're running Gould's flavor of BSD4.3, and our version of vi is "3.7, 6/7/85". ># Bill Stewart, AT&T Bell Labs 2G218, Holmdel NJ 1-201-949-0705 ihnp4!ho95c!wcs -- Clark Morgan, Tektronix Lab Instruments Engineering (503) 627-3545 clarkm@tekig4.LEN.TEK.COM | {...,decvax,uw-beaver}!tektronix!tekig4!clarkm US Mail: Tektronix, P.O. Box 500, DS 39-087, Beaverton, OR 97077
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-_-_-_-_-landay@ardent.com (James A. Landay) (08/21/89)
Is there a way to make it so that when ever I hit the TAB key in 'vi' that I get 4 spaces rather than an actual tab? I would rather not have to run expand after running vi, as I would only want to do that if I actually changed the file. Thanks, James landay@ardent.com or landay@cory.berkeley.edu
bryden@vax1.acs.udel.EDU (Christopher F. Bryden) (08/22/89)
In article <7901@ardent.UUCP> landay@ardent.com (James A. Landay) writes: }Is there a way to make it so that when ever I hit the TAB key }in 'vi' that I get 4 spaces rather than an actual tab? I would }rather not have to run expand after running vi, as I would only }want to do that if I actually changed the file. This isn't what you want to know, but... :%s/\ /\ \ \ \ /g ^ ^ ^ ^ ^ tab four spaces -- arpa : bryden@vax1.acs.udel.edu | Just another person with his foot so far bitnet: AIT05167 at ACSVM | down his throat that he's sh*ting shoelaces. plato : bryden/itpt/udel ------------------ Who? Me? Naw... Yes? uucp : ...{unidot,uunet}!cfg!udel!udccvax1!bryden | You've got to be kidding.
sgordon@hpindwa.HP.COM (Shaun Gordon) (08/22/89)
> Is there a way to make it so that when ever I hit the TAB key > in 'vi' that I get 4 spaces rather than an actual tab? I would > rather not have to run expand after running vi, as I would only > want to do that if I actually changed the file. While inside vi you can type a colon to get to the command line and then enter: set tabstop=4 If you want tabs to default to 4 you should create a file .exrc in you home directory (if it doesnt already exist) and put the set command in it. It should look like it does above (i.e. no colon.) By the way, if you want to see what other options you can change in vi, you can type a colon and then: set all and this will show you all of the options. I hope this helps. -Shaun
ghe@nucthy.physics.orst.edu (Guangliang He) (08/23/89)
In article <36790001@hpindwa.HP.COM> sgordon@hpindwa.HP.COM (Shaun Gordon) writes: => Is there a way to make it so that when ever I hit the TAB key => in 'vi' that I get 4 spaces rather than an actual tab? I would => rather not have to run expand after running vi, as I would only => want to do that if I actually changed the file. = =While inside vi you can type a colon to get to the command line and then enter: = =set tabstop=4 = [deleted text] No, 'set tabstop=4' does not do what he requested in the original post. He wants REAL space. 'set tabstop=4' makes tabs look like 4 spaces but if you do a 'set list', you can see tab still there. On this question, I don't see any easy solution. ----------------------------------------------------------------------- | USMAIL: Guangliang He | INTERNET: ghe@PHYSICS.ORST.EDU Department of Physics | BITNET: hegl@ORSTVM.BITNET Oregon State University | Corvallis, OR 97331 | PHONE: (503) 737-4631 | -----------------------------------------------------------------------
kevin@client1.DRETOR.UUCP (Socrates) (08/23/89)
In article <36790001@hpindwa.HP.COM> sgordon@hpindwa.HP.COM (Shaun Gordon) writes: >> Is there a way to make it so that when ever I hit the TAB key >> in 'vi' that I get 4 spaces rather than an actual tab? I would >> rather not have to run expand after running vi, as I would only >> want to do that if I actually changed the file. > >While inside vi you can type a colon to get to the command line and then enter: > >set tabstop=4 > This does not appear to be what is desired here. I interpret this as one of the standard vi gripes when indenting by half-tabs. (If you use the above solution then what appears fine from within vi expands to tabstops at 8 columns by cat, more, etc...) There is no easy solution for this, that I have found, however there is a kludge that you can insert into your .exrc. It involves the :map! functions. :map allows you to redefine key meanings, and the ! means that the new definitions apply only within insert mode. The solution I use is to redefine a tab character as four spaces. Only one problem with direct implementation: vi won't recognize the four spaces as existing since it (nicely?) removes whitespace from definitions. To get around this I exit insert mode, then reenter with four spaces entered immediately. There is no noticeable slowdown to perform these extra operations. (I'm using vi on a Sun 3/50 BSD4.2) Here then is the command line to do it: :map! <CTRL-V><CTRL-V><CTRL-I> <CTRL-V><ESCAPE>a (ends with 4 spaces) Hope this is what you are after. -- --- Kevin Picott NTT Systems, Inc., Toronto, Ontario "There can be no offense where none is taken" - Japanese Proverb kevin@zorac.dciem.dnd.ca, or on some sites kevin@zorac.ARPA
andyb@coat.com (Andy Behrens) (08/23/89)
>In article <36790001@hpindwa.HP.COM> Shaun Gordon writes: > Is there a way to make it so that when ever I hit the TAB key > in 'vi' that I get 4 spaces rather than an actual tab? I would > rather not have to run expand after running vi, as I would only > want to do that if I actually changed the file. I assume that you simply want to indent the left margin by 4, 8, 12, etc., spaces. As has been pointed out, ":set tabstop=4" will not work, because it redefines the meaning of tabs instead of using spaces. What you want is :set shiftwidth=4 (:set sw=4), possibly combined with :set autoindent (:set ai) Now, DON'T use the tab key at the left margin; use ^T instead. Each ^T will move 4 positions to the right (inserting combinations of tabs and spaces to get to the correct column). Each ^D at the left margin will move 4 positions to the left. (I suppose you could map TAB into ^T if you wanted to). As an extra bonus, you can now use the "<" and ">" commands to shift a previously-typed block of lines left or right. >> will shift 1 line 6>> will shift 6 lines >} will shift everything to the end of a paragraph >% if the cursor is over a brace or parenthesis, will shift everything until the matching brace or parenthesis. -- Live justly, love gently, walk humbly. Andy Behrens andyb@coat.com uucp: {harvard,rutgers,decvax}!dartvax!coat!andyb bitnet: andyb%coat@dartcms1 Burlington Coat, PO Box 729, Lebanon, N.H. 03766 (603) 448-5000
loo@mister-curious.sw.mcc.com (Joel Loo) (08/23/89)
Someone wrote (sorry forgot who): >=> Is there a way to make it so that when ever I hit the TAB key >=> in 'vi' that I get 4 spaces rather than an actual tab? I would >=> rather not have to run expand after running vi, as I would only >=> want to do that if I actually changed the file. This works on my Unix: :map! ^V<tab> ^V<sp>^V<sp>^V<sp>^V<sp> Of course, to type in a ^V you will have to type ^V^V, making the command to be actually: :map! ^V^V<tab> ^V^V<sp>^V^V<sp>^V^V<sp>^V^V<sp> hope this helps [tm] -Joel
dce@Solbourne.COM (David Elliott) (08/23/89)
In article <36790001@hpindwa.HP.COM> sgordon@hpindwa.HP.COM (Shaun Gordon) writes: >> Is there a way to make it so that when ever I hit the TAB key >> in 'vi' that I get 4 spaces rather than an actual tab? I would >> rather not have to run expand after running vi, as I would only >> want to do that if I actually changed the file. I think all solutions to this assume that "I get 4 spaces" really means "I get to the next column for which column%4 == 0". To get exactly 4 spaces for a tab is pretty hard in the general case, since it's hard to map tab and hard to get spaces in the mapping. What you really need, as Shaun points out, is >set tabstop=4 In addition, you should set shiftwidth=4 so that > and < will use the expected units. -- David Elliott dce@Solbourne.COM ...!{uunet,boulder,nbires,sun}!stan!dce "I had a dream that my kids had been reparented." - Tom LaStrange
landay@mrk.ardent.com (James A Landay) (08/24/89)
In article <36790001@hpindwa.HP.COM> sgordon@hpindwa.HP.COM (Shaun Gordon) writes: >> Is there a way to make it so that when ever I hit the TAB key >> in 'vi' that I get 4 spaces rather than an actual tab? I would >> rather not have to run expand after running vi, as I would only >> want to do that if I actually changed the file. > >While inside vi you can type a colon to get to the command line and then enter: > >set tabstop=4 > >If you want tabs to default to 4 you should create a file .exrc in you home >directory (if it doesnt already exist) and put the set command in it. It >should look like it does above (i.e. no colon.) > This solution does not have the desired result. It just causes TABs to be displayed as 4 blanks when I'm in vi. When other people look at the file or cat or more, etc... it will come out as 8 spaces. I want vi to insert 4 blanks whenever I type TAB, not an actual TAB character. James landay@ardent.com or landay@cory.berkeley.edu * *
steve@nuchat.UUCP (Steve Nuchia) (08/24/89)
In article <36790001@hpindwa.HP.COM> sgordon@hpindwa.HP.COM (Shaun Gordon) writes: >> Is there a way to make it so that when ever I hit the TAB key >> in 'vi' that I get 4 spaces rather than an actual tab? I would >While inside vi you can type a colon to get to the command line and then enter: >set tabstop=4 I don't recommend that, since everything else in the world -- print formatters and other people's screens to name two -- will continue to assume tabstops at 8 columns. In fact there is no way to make vi insert anything other than a tab when you hit the tab key. What I do recomend is leaving tabstop alone and setting shiftwidth=4. This allows you to use ^T as a soft tab and << and >> will shift lines in four column increments -- just right for programming. Most people will find it handy to also set autoindent. ^D in insert mode will delete one shiftwidth of leading indentation. Another handy vi idiom for programmers -- you can shift a whole block of C by combining the < or > shift operators with the % (bracket match) command as a target specifier. -- Steve Nuchia South Coast Computing Services uunet!nuchat!steve POB 890952 Houston, Texas 77289 (713) 964 2462 Consultation & Systems, Support for PD Software.
kyriazis@plato.rdrc.rpi.edu (George Kyriazis) (08/24/89)
In article <12187@orstcs.CS.ORST.EDU> ghe@nucthy.PHYSICS.ORST.EDU (Guangliang He) writes: >In article <36790001@hpindwa.HP.COM> sgordon@hpindwa.HP.COM (Shaun Gordon) writes: >=> Is there a way to make it so that when ever I hit the TAB key >=> in 'vi' that I get 4 spaces rather than an actual tab? I would >=> rather not have to run expand after running vi, as I would only >=> want to do that if I actually changed the file. >= Well, while in vi you can do :g/./s/ / /g ^ ^ | 4 spaces a TAB character That will replace every TAB with 4 spaces in your whole file. George Kyriazis kyriazis@turing.cs.rpi.edu kyriazis@rdrc.rpi.edu ------------------------------
istvan@hhb.UUCP (Istvan Mohos) (08/24/89)
landay@ardent.com (James A. Landay) writes: >Is there a way to make it so that when ever I hit the TAB key >in 'vi' that I get 4 spaces rather than an actual tab? I would >rather not have to run expand after running vi, as I would only >want to do that if I actually changed the file. Assuming that you are interested in this transform only while in insert mode, you have two choices: Interactive mapping: hit single character______________ : (to get to the command line) type four characters______________ map! hit the following sequence of keys control-V control-V tab space control-V control-V space space space space return OR, adding the mapping by editing EXINIT under vi (in BSD .cshrc file; sysV syntax is slightly different): setenv EXINIT 'set <other_options_here>|map\!<mapstring>' <mapstring> is entered as the following sequence of bytes: control-V control-V tab space control-V control-V space space space space -- Istvan Mohos {ihnp4,decvax,allegra}!philabs!hhb!istvan HHB Systems 1000 Wyckoff Ave. Mahwah NJ 07430 201-848-8000 ====================================================================
sgordon@hpindwa.HP.COM (Shaun Gordon) (08/24/89)
> Is there a way to make it so that when ever I hit the TAB key > in 'vi' that I get 4 spaces rather than an actual tab? I would > rather not have to run expand after running vi, as I would only > want to do that if I actually changed the file. Sorry, I misunderstood your question. I thought that you just wanted to know how to tab 4 spaces instead of 8. Kindly ignore my last posting. To salvage my image as "someone who isn't entirely clueless," I will offer the following partial (although not very elegent) solution. First, set the following two options. set shiftwidth=4 set tabstop=200 Now all you have to do is use ^T instead of using the TAB key. The variable 'shiftwidth' sets the number of spaces to "tab". You need to set 'tabstop' to a large number to stop vi from replacing your ^T tabs with real tabs (i.e. if you had tabstop=8 and shiftwidth=4 and you pressed ^T twice, vi would replace your spaces with a real tab.) Another thing to note is that if you use ^T at the beginning of a line, you can't use your backspace key to erase one of your "tabs". You will need to use ^D to go backwards one tab. On my version of vi, this solution works, however, I seem to recall that when I used vi at UC Berkeley, that ^T only worked at the beginning of lines and wouldn't do anything if you tried to use it if there was anything other than whitespace to the left of the cursor. If this is the case, you will not be able to tab anywhere except before the first character of a line. If this works, the next step might be to figure out how to map the tab key to ^T in your .exrc file (I couldn't figure it out.) Hope this works for you -- please let me know what happens, and if you have any questions, feel free to mail me. -Shaun
mvp@v7fs1.UUCP (Mike Van Pelt) (08/24/89)
> Is there a way to make it so that when ever I hit the TAB key > in 'vi' that I get 4 spaces rather than an actual tab? I would > rather not have to run expand after running vi, as I would only > want to do that if I actually changed the file. The :map! ^V^V<tab> ^V^V<sp><sp><sp><sp> and set shiftwidth=4 solution that's been mentioned does part of it. What a lot of people seem to be missing is that YOU DON'T WANT ANY TABS AT ALL in the output text -- just spaces, as in the output from expand. To do that, set tabstop=99 in your .exrc file, and autoindent will put in spaces instead of tabs at the beginning of your lines. (Assuming lines don't grow beyond 99 columns, anyway...) Then, when you edit someone else's file with tabs in it, you'll see awful garbage, and have to run the whole file through expand -4. You'll only need to do this once, from then on, the file will be nice and tabless. A quick way to do this is :$ to the end of the file, set a mark with ma, :0 back to the top, then type !'aexpand -4<cr> This runs the text of the file through expand, deletes it all, then replaces it with the output from expand. Note, if you mistype the expand command, it will replace all your text with the error message. The u command will get it back... just make sure caps lock didn't get set somehow, as upper-case U will make it impossible to undo the command. (This one bites me every so often... I hate the F1 caps-lock on the Sun!!!!) -- Mike Van Pelt "Beware the first release, my son, Headland Technology/Video 7 and shun the frumious 1.0" ...ames!vsi1!v7fs1!mvp
dts@quad.uucp (David T. Sandberg) (08/24/89)
In article <2068@marvin.Solbourne.COM> dce@Solbourne.com (David Elliott) writes: >In article <36790001@hpindwa.HP.COM> sgordon@hpindwa.HP.COM (Shaun Gordon) writes: >>> Is there a way to make it so that when ever I hit the TAB key >>> in 'vi' that I get 4 spaces rather than an actual tab? > >I think all solutions to this assume that "I get 4 spaces" really means >"I get to the next column for which column%4 == 0". To get exactly >4 spaces for a tab is pretty hard in the general case, since it's >hard to map tab and hard to get spaces in the mapping. Right, but I'm fairly certain that the idea was to end up with no tabs in the file. I recently ran into a situation where this would have been helpful; I had a text file which I wanted to edit mostly with vi, but also wanted to load into Uniplex on occasion. Editing the file without using the tabstops was bordering on ridiculous, and even if the system had featured an "expand", I wouldn't have wanted to run the file through the filter several times a day. Unfortunately, I arrived at the conclusion that there was no really good way to accomplish this. -- David Sandberg - Quadric Systems "Strike Hard, Strike Sure" PSEUDO: dts@quad.uucp Bomber Command, R.A.F. ACTUAL: ..uunet!rosevax!sialis!quad!dts
wyle@inf.ethz.ch (Mitchel Wyle) (08/24/89)
In article <7901@ardent.UUCP> landay@ardent.com (James A. Landay) writes: >Is there a way to make it so that when ever I hit the TAB key >in 'vi' that I get 4 spaces rather than an actual tab? I would >rather not have to run expand after running vi, as I would only >want to do that if I actually changed the file. >landay@ardent.com You probably want something more complicated than what you specified. What you just specified can be done with map! ^V^I <four spaces> or abbr instead of map! What you want is something which will ALIGN columns with spaces, using tab-stops every 4 spaces. I use tabs while I'm typing, then pipe the file through expand(1) to get spaces before saving or every so often. I suspect that expand can take params about how wide tab-stops are, etc. Any solutions which are more elegant?? -Mitch
norm@oglvee.UUCP (Norman Joseph) (08/24/89)
From article <15184@dartvax.Dartmouth.EDU>, by andyb@coat.com (Andy Behrens): >>In article <36790001@hpindwa.HP.COM> Shaun Gordon writes: >> Is there a way to make it so that when ever I hit the TAB key >> in 'vi' that I get 4 spaces rather than an actual tab? > > What you want is > > :set shiftwidth=4 (:set sw=4), possibly combined with > :set autoindent (:set ai) > > Now, DON'T use the tab key at the left margin; use ^T instead. Each ^T > will move 4 positions to the right (inserting combinations of tabs and > spaces to get to the correct column). Each ^D at the left margin will > move 4 positions to the left. This is -almost- right. As Andy says, ^T will insert enough -tabs- and spaces to get you to the next shiftwidth. It looks at the setting of ``tabstops'' to see how many tabs it needs to use. If tabstops=4 and shiftwidth=4 then it will insert one tab to move one shiftwidth. If shiftwidth is 6, it will use one tab and two spaces to get to the next shiftwidth column. The trick here is to set tabstops to a number much -larger- than shiftwidth. For example, I set my tabstops to 78. What this means is that when you hit ^T for the next shiftwidth position, vi sees that inserting a tab will move you 78 columns to the right, so it has no choice but to use -real- spaces to move you shiftwidth columns. This has worked for me with much success. There -is- a single drawback, though. If you edit a file that has -real- tabs in it it will look -awful- until you either 1) set tabstops=4 if you don't want to remove those tabs, or 2) do one of these: ``:%s/<tab>/<4 spaces>/g''. As another poster pointed out, to make life easier, place all these ``set'' commands in vi's startup file, .exrc, in your home directory. For example, mine looks like this: % cat ~/.exrc set ai set nomesg set report=1 set shell=/bin/csh set shiftwidth=4 set showmatch set tabstop=78 set terse set wrapmargin=1 % -- Norm Joseph - Oglevee Computer System, Inc. UUCP: ...!{pitt,cgh}!amanue!oglvee!norm /* you are not expected to understand this */
les@chinet.chi.il.us (Leslie Mikesell) (08/25/89)
In article <242@quad.uucp> dts@quad.uucp (David T. Sandberg) writes: >Right, but I'm fairly certain that the idea was to end up with no >tabs in the file. I recently ran into a situation where this would >have been helpful; I had a text file which I wanted to edit mostly >with vi, but also wanted to load into Uniplex on occasion. Editing >the file without using the tabstops was bordering on ridiculous, and >even if the system had featured an "expand", I wouldn't have wanted >to run the file through the filter several times a day. What's wrong with: pr -t -e to expand the tabs to the positions you want? (perhaps this is why you don't have expand...) My sysVr3.2 manual page for pr shows options also for -eck for expansion where c is the optional tab character and k is an optional digit for the size of a tabstop (default=8) -ick for the opposite i.e. replace spaces w/tabs where possible. >Unfortunately, I arrived at the conclusion that there was no really >good way to accomplish this. Unfortunately the permuted index does not show tabs as being related to the pr command (AT&T SvsVr3.2 for '386). Les Mikesell
morrell@hpsal2.HP.COM (Michael Morrell) (08/29/89)
> A quick way to do this is :$ to the end of the file, set a mark with > ma, :0 back to the top, then type !'aexpand -4<cr> This runs the > text of the file through expand, deletes it all, then replaces it with > the output from expand. You can do this without the mark by using "!Gexpand -4<cr>". The "G" will apply the expand from the current line to the end of the file. Michael
jws@hpcljws.HP.COM (John Stafford) (08/31/89)
BEWARE: Most versions of vi I've seen can trash your file if you pipe too much though a filter program (like expand). I have had files trashed doing exactly 1G!Gexpand. You get a block of lines replaced with blank lines and the original lines get moved someplace else and rotated to various degrees. I believe a race condition is involved. While the failure is rare and correlates positively with increasing file size, I have never known exactly what triggers it (I'm sure somebody reading this knows and can enlighten us).
les@chinet.chi.il.us (Leslie Mikesell) (09/04/89)
In article <720011@hpcljws.HP.COM> jws@hpcljws.HP.COM (John Stafford) writes: >BEWARE: Most versions of vi I've seen can trash your file if you pipe >too much though a filter program (like expand). I have had files >trashed doing exactly 1G!Gexpand. You get a block of lines replaced >with blank lines and the original lines get moved someplace else and >rotated to various degrees. >I believe a race condition is involved. While the failure is rare and >correlates positively with increasing file size, I have never known >exactly what triggers it (I'm sure somebody reading this knows and can >enlighten us). Vi must be using the text buffer to read the output from the process at the same time it is sending the original text to the process. This seems kind of silly since a copy is made so you can "undo" the command. If you notice the problem soon enough, "undo" will fix it, but I've had enough trouble that if the file is more than a few pages I always write the file out, delete the buffer, and read the process input back in: :w<return>:1,$d<return>:0r !cmd %<return> doesn't take much longer, doesn't screw up, and it gives you more of a chance to recover the original copy if you decide the filter did not do the desired operation. Les Mikesell