javey@hybrid.UUCP (Shahram Javey) (09/13/90)
Is there a way to edit multiple files in vi so that one could move from one file to next and back again?
david@mlacus.oz (David Letcher) (09/19/90)
javey@hybrid.UUCP (Shahram Javey) writes: >Is there a way to edit multiple files in vi so that one could move >from one file to next and back again? specify all required files on command line e.g. $ vi file1 file2 file3 ... you are placed in file1. when finished editing this file use :w to write away all changes followed by :n to get to the next file. use :e# to return to the LAST file edited. use :e filename to edit any file.
wyle@inf.ethz.ch (Mitchell Wyle) (09/19/90)
In <630@mlacus.oz> david@mlacus.oz (David Letcher) explains: >javey@hybrid.UUCP (Shahram Javey) asked: > >>Is there a way to edit multiple files in vi so that one could move >>from one file to next and back again? ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ He wants to jump around between files, cutting, pasting, viewiing, etc. as emacs users do with their several windows. >specify all required files on command line But he may not know which files are required when he starts! >use > >:e# > >to return to the LAST file edited. That's the ticket! I have never seen any good, clear, motivating examples of the "alternate file" editing feature(s) in vi. Me? I use csh job control when I do text editing and ctags, ^] :tag when I edit program code. I must admit I leave vi a lot and use csh with a bunch of vi's hanging around stopped in the background... % vi file1 ^Z % vi file2 ^Z % vi file3 ^Z % %2 ^Z % %3 etc. I often cut pieces out of files, write them to temporary files, then read them into other files. I KNOW it is possible to perform these operations without leaving vi, as in: % vi file1 :e file2 [yank stuff into some buffer, e.g. "a9yy (yank 9 lines into buffer a)] :e# [put stuff where I want it. e.g. "ap (put buffer a here)] but I have not yet become so adept at vi that I use this way to yank, cut, and paste between different files without leaving vi. I suppose that most of us receive poor training at the outset and fall into bad habits. The vi books all suck in how they teach you to use these features which is one reason I am writing a better one. >use > >:e filename > > >to edit any file. Yeah!
dlw@palmetto.cis.ufl.edu (Dave Wilson) (09/19/90)
In article <8652@neptune.inf.ethz.ch> wyle@inf.ethz.ch (Mitchell Wyle) writes: > >That's the ticket! I have never seen any good, clear, motivating examples >of the "alternate file" editing feature(s) in vi. Me? I use csh job The best vi tip I ever got was the following mapping in my .exrc file: map g :e#^M This lets me toggle between two files without even thinking about it. Combining this with the character buffers allows me to cut and paste between the two files without too much difficulty. What I really want, though, is the multiple buffers like emacs. Way down on my list of things to do is an XWindows shell around elvis or stevie that gives menu support for multiple files. Or is there something like that out there already? Dave Wilson dlw@beach.cis.ufl.edu
tmb@ai.mit.edu (Thomas M. Breuel) (09/20/90)
In article <24478@uflorida.cis.ufl.EDU>, dlw@palmetto.cis.ufl.edu (Dave Wilson) writes: |> The best vi tip I ever got was the following mapping in my .exrc file: |> |> map g :e#^M |> |> This lets me toggle between two files without even thinking about it. |> Combining this with the character buffers allows me to cut and paste between |> the two files without too much difficulty. Try Control-^.
rick@tetrauk.UUCP (Rick Jones) (09/20/90)
In article <1990Sep13.030424.27298@hybrid.UUCP> javey@hybrid.UUCP (Shahram Javey) writes: >Is there a way to edit multiple files in vi so that one could move >from one file to next and back again? Just to lob in a few other things: remember that :n file1 file 2 ... sets up a new list of files to edit - same as exiting and doing "vi file1 file2...", but without having to exit :rew goes back to the beginning of the file list :ar shows the list of file names, with the one you're on marked thus [..] If you have autowrite mode on (:set aw), then the current file will be written out automatically if you have changed it when you do any of :n, :rew, ctrl/^ (to switch files, :e# doesn't write out), or :! this saves all the :w's that you otherwise have to keep doing. Useful feature of ctrl/^ with aw mode is that if you do ":e newfile", and vi baulks because you haven't saved changes to the current file, a following ctrl/^ will save the current file, and switch to the newly named file. Anywhere on the command line, including shell escapes, % is the current filename, and # is the last (alternate) filename - hence :e# works. This is useful for quick test compiles, since ":!cc %" will C-compile the current file, writing it out if changed and aw mode is set. Also ! is the last shell command, so repeated compile tests reduce to ":!!". vi is like a Ferrari - it takes time to learn it properly but it's damn fast when you know what you're doing. Have fun -- Rick Jones The definition of atomic: Tetra Ltd. from the Greek meaning "indivisible" Maidenhead, Berks, UK So what is: rick@tetrauk.uucp an atomic explosion?
fyl@ssc.UUCP (Phil Hughes) (09/20/90)
In article <8652@neptune.inf.ethz.ch>, wyle@inf.ethz.ch (Mitchell Wyle) writes: > In <630@mlacus.oz> david@mlacus.oz (David Letcher) explains: > >javey@hybrid.UUCP (Shahram Javey) asked: > >>Is there a way to edit multiple files in vi so that one could move > >>from one file to next and back again? > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ .... much stuff deleted .... > but I have not yet become so adept at vi that I use this way to yank, > cut, and paste between different files without leaving vi. I suppose > that most of us receive poor training at the outset and fall into bad > habits. The vi books all suck in how they teach you to use these > features which is one reason I am writing a better one. Really? I thought it was pretty well covered in our VI Pocket Tutorial. Like all our products it isn't designed for WordStar users who want a 500 page book on how to delete a line but, if you can understand a non-redundant explanation I think it does a good job (and I didn't even write it. :-) ) Before you write a "better" book, take a look at it. If you (or anyone else) thinks it "sucks" let us know. We like to write useful, precise books. That's why we offer a free book to anyone who is the first person to report an error in our publications. And, yes, they are available in Germany. Try Fuchbachhandlung fur Informatik und Elektronik in Frankfurt. (Whew, it is so much easier for me to type Computer Literacy or Cucumber. :-) ) -- Phil Hughes, SSC, Inc. P.O. Box 55549, Seattle, WA 98155 (206)FOR-UNIX uunet!pilchuck!ssc!fyl or attmail!ssc!fyl (206)527-3385
Dan_Bloch@TRANSARC.COM (09/21/90)
A few additions to the recent discussion on editing multiple files in vi: - You don't need to specify the files you're editing on the command line. The :n command takes arguments. Also, see next item. - By default when you say :e (or :n or :n #, or control-^ or ...), vi tells you, "No write since last change, :e! to overwrite" or some such, and you have to :w to save changes. If you :set autowrite, vi automatically updates the files on :tag, :n, and :rew commands (not :e), and you really can go back and forth between files with a keystroke. One caveat: autowrite also saves changes if you do a :sh or control-Z. - Much as I like vi, you really can't easily move around among more than two files. The two best ways I know are putting them all on the command line, going through them with :n, and cycling or starting again at the first one with :rew, OR (what I usually do) remembering one file throughout the session, and frequently changing the alternate file. - "Cutting and pasting" between files is almost as easy as within a single file; you just have to use the named buffers for y and d commands. That is, yy will be forgotten when you change files, but "ayy will still be known. [Hot tip: "Ayy appends to the buffer instead of replacing it.] One last note: wyle@inf.ethz.ch (Mitchell Wyle) writes: > ... but I have not yet become so adept at vi that I use this way to yank, > cut, and paste between different files without leaving vi. I suppose > that most of us receive poor training at the outset and fall into bad > habits. The vi books all suck in how they teach you to use these > features which is one reason I am writing a better one. IMHO, A Guide to vi: Visual Editing on the UNIX System, by Dan Sonnenschein, Prentice-Hall, 1987, ISBN 0-13-371311-3 025 is just about the best book on vi imaginable. Chapter 11 is "Cut and Paste Between Files." Dan Bloch dan@transarc.com
jansteen@cwi.nl (Jan van der Steen) (09/21/90)
Dan_Bloch@TRANSARC.COM writes: >A few additions to the recent discussion on editing multiple files >in vi: [stuff deleted...] > - "Cutting and pasting" between files is almost as easy as within a > single file; you just have to use the named buffers for y and d > commands. That is, yy will be forgotten when you change files, but > "ayy will still be known. [Hot tip: "Ayy appends to the buffer > instead of replacing it.] And if you include the following mappings in your .exrc (or EXINIT variable) the cut and yank buffers will be global by default: map D "zD map d "zd map p "zp map P "zP map y "zy map Y "zY -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Jan van der Steen jansteen@cwi.nl Centre for Mathematics and Computer Science (CWI) Kruislaan 413, 1098 SJ Amsterdam, The Netherlands
edp367s@monu6.cc.monash.edu.au (Rik Harris) (09/24/90)
jansteen@cwi.nl (Jan van der Steen) writes: >Dan_Bloch@TRANSARC.COM writes: >>A few additions to the recent discussion on editing multiple files >>in vi: >[stuff deleted...] >> - "Cutting and pasting" between files is almost as easy as within a >> single file; you just have to use the named buffers for y and d >> commands. That is, yy will be forgotten when you change files, but >> "ayy will still be known. [Hot tip: "Ayy appends to the buffer >> instead of replacing it.] >And if you include the following mappings in your .exrc >(or EXINIT variable) the cut and yank buffers will be >global by default: > map D "zD > map d "zd > map p "zp > map P "zP > map y "zy > map Y "zY Hmmmm, when I try this it says "no tail recursion". My main concern was the command 'dd' but when I tried this to check, it gave me the above diagnostic. Do you actually use this???? rik. -- Rik Harris - edp367s@monu6.cc.monash.edu.au | Build a system that Faculty of Computing and Information Technology, | even a fool can use, Monash University, Caulfield Campus, Australia | and only a fool will (say that with your mouth full!) | want to use it.
jansteen@cwi.nl (Jan van der Steen) (09/24/90)
edp367s@monu6.cc.monash.edu.au (Rik Harris) writes: >jansteen@cwi.nl (Jan van der Steen) writes: >>Dan_Bloch@TRANSARC.COM writes: >>>A few additions to the recent discussion on editing multiple files >>>in vi: >>[stuff deleted...] >>> - "Cutting and pasting" between files is almost as easy as within a >>> single file; you just have to use the named buffers for y and d >>> commands. That is, yy will be forgotten when you change files, but >>> "ayy will still be known. [Hot tip: "Ayy appends to the buffer >>> instead of replacing it.] >>And if you include the following mappings in your .exrc >>(or EXINIT variable) the cut and yank buffers will be >>global by default: >> map D "zD >> map d "zd >> map p "zp >> map P "zP >> map y "zy >> map Y "zY >Hmmmm, when I try this it says "no tail recursion". >My main concern was the command 'dd' but when I tried this to check, it >gave me the above diagnostic. >Do you actually use this???? I'm very sorry but when I tested the above macros I wasn't aware that I was running elvis the vi clone recently posted to (I think it was) comp.sources.misc. Unlike vi, elvis *does* allow the user to map vi primitives to keys with the same name. Jan van der Steen -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Jan van der Steen jansteen@cwi.nl Centre for Mathematics and Computer Science (CWI) Kruislaan 413, 1098 SJ Amsterdam, The Netherlands
reddy@lion.austin.ibm.com (/150000;Austin) (09/24/90)
Rick Harris writes ... >> map D "zD >> map d "zd >> map p "zp >> map P "zP >> map y "zy >> map Y "zY > Hmmmm, when I try this it says "no tail recursion". To avoid this type a blank after the last letter. I have mapped q to :wq this way.
rick@tetrauk.UUCP (Rick Jones) (09/25/90)
In article <gayHz7P0BwwZ0f5VER@transarc.com> Dan_Bloch@TRANSARC.COM writes: > >A few additions to the recent discussion on editing multiple files >in vi: > > One caveat: autowrite also saves changes if you do a :sh or control-Z. ^^^ A nitpick: :sh DOES NOT write out when autowrite is on :! <command> DOES so :sh is not the same as :!sh This is in fact useful to know if you habitually have autowrite on and then want a shell without writing out the file - like if you want to look at something in the unedited version before scribbling on it! -- Rick Jones The definition of atomic: Tetra Ltd. from the Greek meaning "indivisible" Maidenhead, Berks, UK So what is: rick@tetrauk.uucp an atomic explosion?
dylan@ibmpcug.co.uk (Matthew Farwell) (09/25/90)
In article <jansteen.654177942@piring.cwi.nl> jansteen@cwi.nl (Jan van der Steen) writes: > >[ stuff about tail recursion in vi] > >I'm very sorry but when I tested the above macros I wasn't aware that >I was running elvis the vi clone recently posted to (I think it was) >comp.sources.misc. >Unlike vi, elvis *does* allow the user to map vi primitives to keys >with the same name. I don't think this a very good idea. Couple of reasons. 1) If elvis were to allow the macro:- :map d "xd If I were to then type 'dd' What should it do? I think that "xd"xd would have unpredictable (to the novice) results. If say he wanted to delete a line then move to the end of the file (using ddG), things would get quite surprising. If you want recursion, use 2 macros which reference each other. 2) With the above mapping, If I were then to:- :map D dG should it use the primitive d or the mapped d? If it were to use the mapped d then elvis would get very confused, so I'll assume it uses the primitive d once again. Does this mean when I map a key, I can't use it in another mapping? This sort of behaviour is very nonstandard, and people who use it, when they migrate to real vi will get very confused when all their macros don't work. You never know, they might actually have to start learning how to use vi properly. 3) While im on the subject, why does elvis handle long lines so badly? ie, it has them off the end of the screen? This causes an awful problem when you've got a lot of long lines + a reasonably slow machine/line. (Try editing a file with a lot of lines over 80 chars on a line at 1200 baud. Then do a lot of 0$'s.) Why can't people who write vi clone write vi clones? Things are done like they are in vi for good reasons. Dylan. -- Matthew J Farwell | Email: dylan@ibmpcug.co.uk The IBM PC User Group, PO Box 360,| ...!uunet!ukc!ibmpcug!dylan Harrow HA1 4LQ England | CONNECT - Usenet Access in the UK!! Phone: +44 81-863-1191 | Sun? Don't they make coffee machines?
dattier@ddsw1.MCS.COM (David W. Tamkin) (09/26/90)
edp367s@monu6.cc.monash.edu.au (Rik Harris) wrote in <1990Sep24.053330.3024@monu6.cc.monash.edu.au>: | jansteen@cwi.nl (Jan van der Steen) writes: | >And if you include the following mappings in your .exrc | >(or EXINIT variable) the cut and yank buffers will be | >global by default: | | > map D "zD | > map d "zd | > map p "zp | > map P "zP | > map y "zy | > map Y "zY | | Hmmmm, when I try this it says "no tail recursion". | | My main concern was the command 'dd' but when I tried this to check, it | gave me the above diagnostic. I saw three problems with those mappings: (1) you cannot use more than one named register to save more than one thing at a time, (2) you cannot capitalize the register name to append instead of replacing, and (3) using ndd or nyy to delete or yank n whole lines becomes hopeless, because d" and y" are not legitimate command sequences. (Since in most vi versions Y does yy instead of doing y$, #3 is not a problem for yanking.) Better to do without the automatic "z and keep the flexibility. David Tamkin Box 7002 Des Plaines IL 60018-7002 708 518 6769 312 693 0591 MCI Mail: 426-1818 GEnie: D.W.TAMKIN CIS: 73720,1570 dattier@ddsw1.mcs.com
kirkenda@eecs.cs.pdx.edu (Steve Kirkendall) (09/27/90)
In article <1990Sep25.130305.9858@ibmpcug.co.uk> dylan@ibmpcug.CO.UK (Matthew Farwell) writes: >In article <jansteen.654177942@piring.cwi.nl> jansteen@cwi.nl (Jan van der Steen) writes: >>I'm very sorry but when I tested the above macros I wasn't aware that >>I was running elvis the vi clone recently posted to (I think it was) >>comp.sources.misc. >>Unlike vi, elvis *does* allow the user to map vi primitives to keys >>with the same name. > >I don't think this a very good idea. Couple of reasons. > [ examples deleted ] >This sort of behaviour is very nonstandard, and people who use it, when >they migrate to real vi will get very confused when all their macros >don't work. You never know, they might actually have to start learning >how to use vi properly. I agree that people should think twice before using any undocumented differences between vi and elvis. Actually, I'm surprised that :map d "zd even comes close to working. Dylan's correct in saying that it won't work for "dd". Incidently, Elvis currently has no "remap" option; it always acts as though remapping had been turned off, via ":set noremap". The real vi normally has remapping turned on. This is why they acted differently. >3) While im on the subject, why does elvis handle long lines so badly? >ie, it has them off the end of the screen? This causes an awful problem >when you've got a lot of long lines + a reasonably slow machine/line. >(Try editing a file with a lot of lines over 80 chars on a line at 1200 >baud. Then do a lot of 0$'s.) Why can't people who write vi clone write >vi clones? Things are done like they are in vi for good reasons. Practically all of my machines have memory-mapped video -- including the Minix machine that I wrote Elvis for. I haven't run anything at 1200 baud in years. And the "long line on multiple rows" feature of vi is hard to implement well, and I was never particularly fond of it to begin with. In writing Elvis, my goal was to produce something that FELT like vi, not something that LOOKED like vi. I figured my eyes could adjust to any differences a lot easier than my fingers could. I *DO* intend to go back and add the "long line on multiple rows" display style eventually. Other things take priority, though. BTW, I get as many comments in favor of sideways scrolling as I do against it. >Dylan. >-- >Matthew J Farwell | Email: dylan@ibmpcug.co.uk ------------------------------------------------------------------------------- Steve Kirkendall kirkenda@cs.pdx.edu uunet!tektronix!psueea!eecs!kirkenda
monty@sagpd1.UUCP (Monty Saine) (09/28/90)
Hello, I tried responding to the thread (and to the person who appears to be the author of Elvis) via e-mail and something in this message keeps blowing my mailer up, sigh... Anyway, I recently requested the executable for elvis for my PC and some kind sole sent it to me, alas after uudecodeing it and un zooing it and then kermitng down to my PC, it will not run. System locks up forcing a hard reset (ctrl-alt-del does not work). If someone else can send me a copy, maybe done up as in an auto-dearcing type format I can get it to run. Does elvis need any support files to run? is an EXTINT variable required? any ideas? All help appreciated, Thanks in advance, Monty Saine