tchrist@convex.COM (Tom Christiansen) (12/06/90)
In article <joshi.660440350@m.cs.uiuc.edu> joshi@cs.uiuc.edu (Anil Joshi) writes: >The problem I find with these editors is that the manuals are hard to >get. One has to read the research papers that were written by the >original authors etc. Why can't there be a reasonable and comprehensive >manual with lots of examples? There are books on vi available. Go to a good technical bookstore. >Talking about ex, one can use abbreviations to do a lot of good stuff but the >ex macros (I am calling the abbreviations macros) are also key stroke >dependent (like having to hit ctrl-v before inserting other control >chars. into the macro.). Is there some way of getting parameters to the >macros? Not exactly, but I think I can probably do anything you would like done. Post your problem, I'll post an answer. >Another problem which I have not solved yet is that while I am editing a >file and want to change my function keys, can I run some other .exrc >like file from inside the editor? Sure, just use the ":so otherexrc" command. I haven't posted this for a while, so here's my .exrc; it's something to stick in the faces of emacsoids, who think vi is not an extensible editor. Just remember: EMACS belongs in <sys/errno.h> :-) Now, it's true that it doesn't start up particularly quickly on diskless Suns, but what does? It works just fine on my Convex. :-) I've commented out a few things that won't work in all versions. There are pretty extensive comments, but you'll want to try them out to really appreciate the stuff. A couple of these are just for fun, but most are quite helpful. Some are really, really helpful. I've run this all through "cat -v" so that it gets there semi- intact, so you'll have to undo this. A problem is that there are some real carets in here. They are on these maps: \C \l ^X ^Y \r It should be obvious which are real. If you run the file through this filter: perl -pe 's/\^(.)/sprintf("%c",ord($1) &~ 0x40)/ge' It will uncat-v the whole thing, and then you should go fix up the five maps listed above. If you don't have perl (shame on you! :-) then you'll have do it by hand; that substitute doesn't work quite as well in sed. :-) --tom " tom christiansen's .exrc file <tchrist@convex.com> " " set terse " because we prefer terse error messages, set writeany autowrite " because we want to write out our file whenever we can, " like on a :tag, :stop, or :next set tabstop=8 " so tabs look right for us set shiftwidth=4 " so ^T and << are smaller set report=1 " so we our told whenever we affect more than 1 line set nomesg " because being talked to during an edit is aggravating set autoindent " so i don't have to tab in set redraw optimize " keep the screen tidy " " " INPUT MACROS that i always want active " map! ^Z ^[:stop^M " so i can stop in input mode. note that autowrite is set, so map! ^A ^[:stop!^M " will stop me without writing. " map! ^K ^V^[O " lets me do kindof a negative carriage return in input mode. "map! ^B ^[bi " non-destructive ^W "map! ^F ^[Ea " and its inverse " " " ARROW MACROS next four let arrows keys work in insert mode; " map! ^V^[OA ^V^[ka map! ^V^[OB ^V^[ja map! ^V^[OC ^V^[lli map! ^V^[OD ^V^[i " " " Who says you can't emulate emacs in vi? :-) " map! ^B ^V^[i map! ^F ^V^[lli map! ^A ^V^[I map! ^E ^V^[A " " " EXCHANGE MACROS -- for exchanging things " map v xp " exchange current char with next one in edit mode map V :m+1^M " exchange current line with next one in edit mode map! ^P ^V^[hxpa " exchange last typed char with penultimate one in insert mode map = ^^ " edit previously editted file " " " " other macros " map g G " because it's easier to type map ^A :stop!^M " unconditional stop map ' ` " so we return to exact position, not just ^ on 'a or '' map Y y$ " so Y is analagous to C and D map ^R ddu " single-line redraw map ^N :n +/^M " go to next file in arg list, same position " useful for "vi +/string file1 file2 file3" " " " META MACROS, all begin with meta-key '\' ; more later in file " map ^V \ " so can use both ^I and \ for meta-key " map * i^M^[ " split line " map \/ dePo/\<^V^[pA\>^V^["wdd@w " find current word, uses w buffer " map \w :w^M " write out the file " map \C o^V^[k:co.^V^M:s/./ /g^V^Mo^V^[80a ^V^[:-1s;^;:s/;^V^M:s;$;//;^V^M"mdd@m:s/\(.\)./\1/g^V^M:s;^;:-1s/^/;^V^M"mdd@mjdd " center text " " EXECUTION MACROS -- these two are for executing existing lines. " map \@ ^V^["mdd@m " xqt line as a straight vi command (buffer m, use @@ to repeat) map \! 0i:r!^V^["ndd@n " xqt line as :r! command (buffer n, use @@ to repeat) " map \t :r!cat /dev/tty^M " read in stuff from X put buffer " " c-hacking exrc source, useful on c programs et al, but not text " set modelines " so that we spot lines like /* vi:set tabstops=3 */ " at the top of a file, kinda like file-specific exrc commands " set tags=tags\ /mnt/tchrist/tmptags\ /usr/lib/tags " tmptags is so can make tmp tag file of r/o src dirs " by "set d = $cwd;cd;ctags -twd $d/*.[ch];mv tags tmptags;cd $d' " " " BLOCK MACROS -- these make { and } hot keys in insert mode " map! ^O ^V^V^V{^M^V^V^V} ^V^[O^T " this will begin a block, leaving in insert mode map! ^] ^V^[/^V^V^V}^V^Ma " and this will take you past its end, leaving in insert mode " " " " LINT MACRO. deletes all text from "lint output:" and below, (if any) " replacing it with lint output in pretty block comment form. could " do sed work myself, but this is faster. " " the map! is for subsequent map, not by people, " tho /^Lo would make sense. " this is one of those famous time/space tradeoffs map! ^Lo lint output " " and now for the real work map \l Go^M/* ^Lo^M^[/^Lo^MdG:w^Mo/*** ^Lo^[<<:r!lint -u -lc %^V|sed 's/^/ * /'^MGo***/^[N " " indent this for me " map \i :%!indent -i4^M " " COMMENTING MACROS -- these are actually pretty amazing " " from edit mode, this comments a line map ^X ^i/* ^[A */^[^ " " and this undoes it map ^Y :s/\/\* \([^*]*\) \*\//\1^[ " " this next one defeats vi's tail-recursion defeatism " called by 2 maps following this one map! ^N ^V^[:unmap! ^V^V^M^[ " " while in insert mode, this will put you "inside" a comment map! ^X ^V^[:map! ^V^V^M ^V^V^[a^V^V^V^No^[a /* */^[hhi " " while in edit mode, this begins a block comment -- ^N to escape map \c O/*^M * ^M*/^[k:map! ^V^V^M ^V^V^M* ^MA " " and this is for adding more lines to a block comment -- ^N to escape map \o :map! ^V^V^M ^V^V^M* ^MA " " " this stuff (probably) only works with UW vi. " set tagstack " so we can :tag and :pop deeper than 1 level set filestack " so we can tag lookup on files and pop off set path=/mnt/tchrist " so we can say "vi foo" or ":n foo" and look all those places " if the file is relative and not in . set ?S1200:window=8 " if (speed==1200) set window=8 " cause the default is too much. set ?Tcitc:fastfg " if (term==citc) set fastfg " " c-hacking exrc source that only works with UW vi " "set tagprefix " allows abbreviated tags. better than std taglength " set exinit " " things i want active when editing text not programs " set ignorecase " cause this is test set wrapmargin=5 " this sets autowrap 5 from right margin " " map _ i_^V^V^V^H^V^[ll " this character will now be underlined when less'd " map \s :w^Mgo^V^[:$r!spell %^M " spell the file, placing errors at bottom, use \w to find map \n Gdd\/ " for find next spelling error " " " FORMATING MACROS " map \P .,$fmt -75^M " format thru end of document map \p !}fmt -75^M " format paragraph map \f 1G/---^Mj:.,$!fmt -75^M " format message map \e :%!expand -4^M " expand tabs to 4 stops " map \r 1G/^-/^[:r!sed -e '1,/^$/d' -e 's/^./> &/' @ ^[/^-/^[j " read in @, quoted (for MH replies, who link @ to current file) " " ab rrt Return-Receipt-To: tchrist ab CCC CONVEX Computer Corporation ab ccc convex computer corporation ab Chr Christiansen ab Dec December ab dec december ab Feb February ab feb february ab Fri Friday ab fri friday ab Int International ab info information ab Jan January ab jan january ab Mon Monday ab mon monday ab nite night ab Nov November ab nov november ab Oct October ab oct october ab Sat Saturday ab Sep September ab sep september ab tho though ab thru through ab Thu Thursday ab thu thursday ab thur thursday ab tonite tonight ab Tue Tuesday ab tue tuesday ab univ university ab Wed Wednesday ab wed wednesday ab WI Wisconsin ab WI Wisconsin ab Wi Wisconsin ab wi wisconsin ab wi wisconsin ab Xmas Christmas ab xmas christmas " my figners have dyslexia ab covnex convex ab Covnex Convex ab versino version " "set tagstack " so we can :tag and :pop deeper than 1 level "set filestack " so we can tag lookup on files and pop off "set path=/tac/tchrist\ /etc\ /usr/include\ /usr/include/sys " so we can say "vi foo" or ":n foo" and look all those places " if the file is relative and not in . "set ?S1200:window=6 " if (speed==1200) set window=8 " cause the default is too much. "set ?Tcitc:fastfg " if (term==citc) set fastfg " " stuff for text editing that will only work with UW vi " " set up wrapmargin as 75 columns, thus letting me be quoted " this is so dumb. wrapmargin should be absolute not relative " "set ?W80:wrapmargin=5 "set ?W132:wrapmargin=47 "set ?W98:wrapmargin=23 -- Tom Christiansen tchrist@convex.com convex!tchrist "With a kernel dive, all things are possible, but it sure makes it hard to look at yourself in the mirror the next morning." -me
joshi@cs.uiuc.edu (Anil Joshi) (12/07/90)
tchrist@convex.COM (Tom Christiansen) writes: >There are books on vi available. Go to a good technical bookstore. Why are there no manuals? Shouldn't there be some authoritative document somewhere that says that this is vi? I generally found that books on editors (I am speaking from experience of reading books for IBM mainframe packages like DB2, ISPF and VM/CMS) or other vendor software usually for those who do not like manuals. But I like manuals, I like to read them from cover to cover before starting anything. I cannot find a good definitive manual that gives command syntax in alphabetical order with a good index for vi. Could you please suggest how I would go about ordering one? What are the manual numbers? How about emacs? From where can I get the manuals? >Not exactly, but I think I can probably do anything you would like >done. Post your problem, I'll post an answer. Here they are. 1. The join should flow till the next blank line. Not just join together two lines. If I have the margin or some such set at say 72 cols., when I do a join, I have to reformat the entire para by going to the appropriate word (I have to judge this visually) and then split and then join and so on. 2. I want to exclude some number of line from a file I am editing. Like \begin{enumerate} \item \item \item \item \item \item \begin{enumerate} \item \item \item \item \item \item \item \end{enumerate} \item \item \item \item \item \item \end{enumerate} And if I mark the first \item line and the last \item line and exclude all the lines between the marks, I need to see some thing like \begin{enumerate} ...............................21 lines excluded.................... \end{enumerate} I found the above feature to be invaluable in concentrating on parts of the file which are separated from each other. I can do marking and go back and and forth. But I would never get a complete picture of the whole thing. This is like an overview. It will also help in matching paranthesis, begin ends blocks etc. There may be some automatic matching that can be done on vi I am sure which I surely want, but this feature of ISPF would be quite useful for me because I can get an overview of a large part of the document. 3. Once you give me the above, I should be able to find say some string only within the excluded lines, or only within the unexcluded lines. If it is found in the excluded lines, those lines should be unexcluded. ex. /enum/x should give \begin{enumerate} ............................... 6 lines excluded.................... \begin{enumerate} ............................... 7 lines excluded.................... \end{enumerate} ............................... 6 lines excluded.................... \end{enumerate} 4. Is it possible to make the marks visible? Do it only when the line numebring is set. Like as follows. 1 This is my firts lin. 2 This is my second line. a this is line labeled a. 4 This is the 4th line. b This line is marked with b. 5. How do I get just the name of the file I am editing right now? Because, for example if I want to say run this file through a filter and save the output in a file with the same name but different extension, can I do this? Please by no means think that I am trying to prove that vi is really bad or anything, the above are somethings which I honestly like to have and do not have in vi, which I like more than emacs. If I have to chose between these two (because I am stuck with UNIX for rest of my life), I would like to make one of these my standard editor. All the emacs gurus, please post (or e-mail) your solutions too. If there are enough requests from ISPFPhiles, I'll post them here. By the way Tom, thanks for the .exrc It seems to be very interesting. See you all later Anil Joshi -- "Whatever we wish ourselves to be, we have the power to make ourselves. If what we are now has been the result of our own past actions,then it certainly follows that whatever we wish to be in the future, can be produced by our own present actions. how to act." - Vivekananda, Late Nineteenth Century Indian Philosopher
mayoff@cs.utexas.edu (Robert Mayoff) (12/08/90)
In article <joshi.660534836@m.cs.uiuc.edu> joshi@cs.uiuc.edu (Anil Joshi) writes: >tchrist@convex.COM (Tom Christiansen) writes: > >>There are books on vi available. Go to a good technical bookstore. > >Why are there no manuals? Shouldn't there be some authoritative document >somewhere that says that this is vi? Simply go, as Tom Christiansen said, to a technical bookstore and buy almost any book on vi. Most of them, I believe, have command reference lists. Additionally, for the "official" manual, by which I mean "An Introduction to Display Editing With vi" (I think that's the title) by William Joy (author of vi), you could order the document as part of the 4.3BSD Manual Set from USENIX (an extremely useful set of manuals). I don't have the ordering info right now, but I can get it for you if you want - send me e-mail. As for emacs - the GNU Emacs manual comes in softcopy as a LaTeX document (I believe) with the GNU Emacs distribution; you can print it out on whatever equipment you have available. In addition, I think it's possible to order a printed copy from the Free Software Foundation; they'll simply print it out, put on one of those plastic spines, and mail it to you. And that WILL be a complete reference manual. >1. The join should flow till the next blank line. Not just join together >two lines. If I have the margin or some such set at say 72 cols., when I >do a join, I have to reformat the entire para by going to the >appropriate word (I have to judge this visually) and then split and then >join and so on. Since you're simply trying to reflow the paragraph, use the command !}fmt<RETURN> which pipes from the current line through the end of the paragraph through the text filter fmt. The default fmt margin is 72 characters; you could get (for example) 100 characters by typing !}fmt -100<RETURN> > >2. I want to exclude some number of line from a file I am editing. Like This you cannot do with vi. It may be possible with emacs (I don't know). You're right; this is a very useful feature at times. >3. Once you give me the above, I should be able to find say some string >only within the excluded lines, or only within the unexcluded lines. If >it is found in the excluded lines, those lines should be unexcluded. Well, it is easy to search for a pattern within a range of lines, or only on lines which match a pattern (or do NOT match a pattern); but since we don't have excluded lines in vi... >4. Is it possible to make the marks visible? No. >5. How do I get just the name of the file I am editing right now? >Because, for example if I want to say run this file through a filter and >save the output in a file with the same name but different extension, >can I do this? You can type control-g to see the current filename (and a few other tidbits of information). If you want to run a program with the current file as input (with any modifications you have made), you can use (for example, to print the file) :w !lpr<RETURN> If you want to filter the entire file through a program, it's easiest to use 1G!Gfilter<RETURN> If you want to simply write the file to a different name, use :w newfilename >"Whatever we wish ourselves to be, we have the power to make ourselves. I wish to be taller. :-) -- /_ rob <mayoff@cs.utexas.edu> /_ Fun things to do with UNIX (#72 in a series): / cat /dev/zero > /dev/null
steinbac@hpl-opus.hpl.hp.com (Guenter Steinbach) (12/08/90)
In comp.editors, joshi@cs.uiuc.edu (Anil Joshi) writes: > Why are there no manuals? Shouldn't there be some authoritative document The HP-UX manual set contains a 290-page vi/ex tutorial. Also, pick up the vi reference and the vi macro guide from this notesgroup, posted by Maarten Litmaath (maart@cs.vu.nl), I believe. Over the years, I have learned that vi can do anything. Guenter Steinbach gunter_steinbach@hplabs.hp.com (Just a user, not a spokesperson.)
staff@cadlab.sublink.ORG (Alex Martelli) (12/08/90)
joshi@cs.uiuc.edu (Anil Joshi) writes: ... >tchrist@convex.COM (Tom Christiansen) writes: >>There are books on vi available. Go to a good technical bookstore. >Why are there no manuals? Shouldn't there be some authoritative document What is supposed to be the difference between "a book" and "a manual"? You can order essentially the same printed material about vi directly from Hewlett-Packard, if you are their customer, or from Addison-Wesley (or a goot technical bookstore) and in the latter case you will pay a little less and get nice binding and cover and so on; personally, I much prefer buying books from companies who know how to sell books, and computers from companies who know how to sell computers (go over to the comp.os.minix group and ask them how good a job Prentice-Hall is doing about distributing Minix software...:=). I would NOT like to have to use the vi manuals put out by DEC or SUN or IBM rather than the one by HP, simply because the HP one is MUCH better written; I generally stick to HP docs as far as I can even when I'm using other computers. But it sure is GREAT to have such a choice... CAN you buy your "ISPF manual" from Sun, Hp, or Dec? Thought so...:-) >somewhere that says that this is vi? I generally found that books on You now seem to be looking for a STANDARD, as opposed to a "manual". Posix 1003.2 "User portability extension" is, I hear, much delayed; it WILL be out someday, but don't hold your breath. >editors (I am speaking from experience of reading books for IBM >mainframe packages like DB2, ISPF and VM/CMS) or other vendor software >usually for those who do not like manuals. But I like manuals, I like to >read them from cover to cover before starting anything. I cannot find a Oh, a soulmate in one thing at least - I like manuals, too. It is fortunately untrue in the Unix world that "books are for those who don't like manuals" - most books in the O'Reilly Nutshell series, for example, ARE "manuals" in this sense. >good definitive manual that gives command syntax in alphabetical order >with a good index for vi. Could you please suggest how I would go about "definitive", only a STANDARD can be - the IBM-world equivalent would be working directly from SAA specs rather than from the product manuals (you CAN do that... bit hard though), and I don't think an SAA spec exists for ISPF or Xedit, though I could be wrong on that. alphabetical order I can't guarantee (a for append, b for beginning of word, c for change... would be rather a mess presented this way, no???), but I seem to recall it's what you get in a 2-page summary in O'Reilly "Unix in a Nutshell" book (which, however, has no index). >ordering one? What are the manual numbers? How about emacs? From where >can I get the manuals? For vi, look at the Addison-Wesley catalogs, and/or ask your HP rep. For Emacs, you can buy a manual preprinted from the Free Software Foundation, although of course its TEX sources come with the EMACS sources, so you can also format it yourself if you want. If you really need ISBN and manufacturers' codes, I might look them up, but can't you do that yourself just as well? >1. The join should flow till the next blank line. Not just join together >two lines. If I have the margin or some such set at say 72 cols., when I >do a join, I have to reformat the entire para by going to the >appropriate word (I have to judge this visually) and then split and then >join and so on. Oh, that one's easy - !}fmt will do exactly what you want in most machines, !}adjust on HP/UX (...a link to make fmt a synonym for adjust is a good idea...!-), or of course you can change the go-to next-blank-line } movement-command to any other line movement, and/or the reformat-this command to nroff or any other pipeline or script of your choice. This is a STRENGTH area for vi, a perfect example of the power of the filter-some-lines-through-external-command concept; J is just for very minor stuff (:address,address j may be more useful in some cases). Points 2 and 3 have to do with excluding lines from visualization, a pretty Xedit (ISPF too?) concept which is lacking in vi. You kludge similar effects through the :g and :v commands and some filtering out, but it's NOT as nice! Some of the uses you relate, however, are INappropriate for the line-exclude mechanism, and are better served by other vi stuff; for example, you talk about "matching parentheses" - but for THAT you really cannot beat the vi % command - go on a paren, hit %, and you jump to the matching one!!! "visible marks", your point 4, is not in vi either, although some kludge may be available here too (:'a n 1 to get line number of mark a, etc). Not a major point, what? >5. How do I get just the name of the file I am editing right now? control-G, and :f, will give it to you, but not "just" - there will also be info on what line you are on, etc. Is it disturbing? >Because, for example if I want to say run this file through a filter and >save the output in a file with the same name but different extension, >can I do this? The % character in any command will be expanded to the name of the file you are editing, and # will be the name of the alternate file; 1G!Gmyfilter >%.filtered may be something like you want. If you want to PROCESS the name you can do so via the usual unix "editing" mechanisms, eg `basename %` will strip the directory-path, etc. >Please by no means think that I am trying to prove that vi is really bad >or anything, the above are somethings which I honestly like to have and >do not have in vi, which I like more than emacs. If I have to chose Plase by no means think that I am trying to "prove" that vi is really *powerful*, it is NOT - it's just that there usually ARE ways around its limitations to make it livable with, and get the interactivity benefits, to delay the transition to Emacs to when machine-loading problems will be a thing of the past... >between these two (because I am stuck with UNIX for rest of my life), I >would like to make one of these my standard editor. All the emacs gurus, >please post (or e-mail) your solutions too. If there are enough requests from >ISPFPhiles, I'll post them here. If what you want is RAW, ABSOLUTE *POWER* you would DEFINITELY have to go with EMACS - its underlying language is SO incredibly powerful! If you want a reasonable tool, reasonably able to interact with other tools, vi is not so bad. It boils down to this: is an editor's job to enable you to do ANY manipulation to a body of text ("increment by one every number in the file, except any starting with 3.14159, which is to be left alone"... how do you do that in ISPF?), or is it to do typical, "minor", editing operations flawlessly, while being able to cooperate with other, more specialized tools to do other things? Unix philosophy USED TO be the latter... "do ONE job WELL", and so on... while the EMACS approach is definitely the former. To each his own... -- Alex Martelli - CAD.LAB s.p.a., v. Stalingrado 45, Bologna, Italia Email: (work:) staff@cadlab.sublink.org, (home:) alex@am.sublink.org Phone: (work:) ++39 (51) 371099, (home:) ++39 (51) 250434; Fax: ++39 (51) 366964 (work only), Fidonet: 332/401.3 (home only).
les@chinet.chi.il.us (Leslie Mikesell) (12/09/90)
In article <109909@convex.convex.com> tchrist@convex.COM (Tom Christiansen) writes: >Not exactly, but I think I can probably do anything you would like >done. Post your problem, I'll post an answer. Can anyone apply? Here's mine: 1) What is a quick and portable way to reform a paragraph? Macro solutions preferred since most of the machines I use don't have fmt and the ones that have nroff are two slow to use it. A macro involving a pipe to awk might work if it can't be done internally. 2) How do you manipulate arbitrary rectangles of text (copy/delete/move)? Ideally you should only have to position the cursor to the corners to delimit the range. (This is trivial on almost all PC wordprocessing programs these days...). Les Mikesell les@chinet.chi.il.us
les@chinet.chi.il.us (Leslie Mikesell) (12/09/90)
In article <1013@tokio.cs.utexas.edu> mayoff@cs.utexas.edu (Robert Mayoff) writes: >>5. How do I get just the name of the file I am editing right now? >>Because, for example if I want to say run this file through a filter and >>save the output in a file with the same name but different extension, >>can I do this? >You can type control-g to see the current filename (and a few other tidbits of >information). If you want to run a program with the current file as input >(with any modifications you have made), you can use (for example, to print the >file) > :w !lpr<RETURN> I think the % expansion is what he is looking for. Assuming you have written the file recently or have autowrite on, :! program % >%.ext would do what you ask (although if you have modified the file and want to make a backup copy of the original like this, having autowrite enabled will kill you). If you want to get the filename into the editor buffer, you could use :r !echo %. I often go to the end of a c program file and use :r !lint % to check for errors, using the === that lint emits as a marker between the text and the error list. Perhaps not as nice as multiple windows, but it works. Les Mikesell les@chinet.chi.il.us
joshi@cs.uiuc.edu (Anil Joshi) (12/09/90)
mayoff@cs.utexas.edu (Robert Mayoff) writes: >Since you're simply trying to reflow the paragraph, use the command > !}fmt<RETURN> I tried to do this. I got a message that said that something like "}fmt command not found". fmt in /usr/ucb which is in my search path set up in .cshrc. Any ideas why it does not work? I also tried "}!fmt" which does not work either. >>"Whatever we wish ourselves to be, we have the power to make ourselves. >I wish to be taller. :-) Sure. Put yourself through one of those stretching racks. :-) (The quote says that "you need to work for it" but only more elegantly) >-- >/_ rob <mayoff@cs.utexas.edu> > /_ Fun things to do with UNIX (#72 in a series): Amil Joshi -- "Whatever we wish ourselves to be, we have the power to make ourselves. If what we are now has been the result of our own past actions,then it certainly follows that whatever we wish to be in the future, can be produced by our own present actions. how to act." - Vivekananda, Late Nineteenth Century Indian Philosopher
mayoff@cs.utexas.edu (Robert Mayoff) (12/09/90)
In article <joshi.660705889@m.cs.uiuc.edu> joshi@cs.uiuc.edu (Anil Joshi) writes: >mayoff@cs.utexas.edu (Robert Mayoff) writes: >> !}fmt<RETURN> > >I tried to do this. I got a message that said that something like >"}fmt command not found". Well, I get this error message }fmt: Command not found. if I type "!}}fmt". Make sure you are not hitting "}" twice. If that doesn't work, this should still work: :.,/^$/!fmt which pipes from the current line through the next blank line through the fmt program. Note that this will not work if there are no more blank lines in the file. -- /_ rob <mayoff@cs.utexas.edu> /_ Fun things to do with UNIX (#72 in a series): / cat /dev/zero > /dev/null
tchrist@convex.COM (Tom Christiansen) (12/09/90)
In article <1990Dec08.200418.6663@chinet.chi.il.us> les@chinet.chi.il.us (Leslie Mikesell) writes: >Can anyone apply? Here's mine: >1) What is a quick and portable way to reform a paragraph? Macro solutions >preferred since most of the machines I use don't have fmt and the ones that >have nroff are two slow to use it. A macro involving a pipe to awk might >work if it can't be done internally. If you don't have fmt, it's your vendor's fault, and yours, since the source is available on uunet. Get it. >2) How do you manipulate arbitrary rectangles of text (copy/delete/move)? >Ideally you should only have to position the cursor to the corners to >delimit the range. (This is trivial on almost all PC wordprocessing >programs these days...). No, that's not built-in to the program. What's the application? If you just want to swap or delete fields or columns around on the same lines, you could easily do it from within vi itself. (Although it might be more conveniently expressed using a more general-purpose tool.) Just because everything is built-in to a PC program doesn't mean you should do it that way in UNIX. The very *VERY* few times I've wanted to do something not on the same line, it takes me maybe 15 seconds of programming in sed, cut, awk, or perl does the trick. Show me the kind of problem you mean. --tom -- Tom Christiansen tchrist@convex.com convex!tchrist "With a kernel dive, all things are possible, but it sure makes it hard to look at yourself in the mirror the next morning." -me
tchrist@convex.COM (Tom Christiansen) (12/09/90)
In article <joshi.660705889@m.cs.uiuc.edu> joshi@cs.uiuc.edu (Anil Joshi) writes: >>Since you're simply trying to reflow the paragraph, use the command >> !}fmt<RETURN> >I tried to do this. I got a message that said that something like >"}fmt command not found". Did you do that after a colon directive? If so, don't do that. Do it from where you are in the paragraph, not from the :command line. --tom -- Tom Christiansen tchrist@convex.com convex!tchrist "With a kernel dive, all things are possible, but it sure makes it hard to look at yourself in the mirror the next morning." -me
tchrist@convex.COM (Tom Christiansen) (12/10/90)
[This article was stompted on by a phone glitch, and I forgot
to recover it.]
In article <joshi.660534836@m.cs.uiuc.edu> joshi@cs.uiuc.edu (Anil
Joshi) writes, quoting me:
:>There are books on vi available. Go to a good technical bookstore.
:
:Why are there no manuals? Shouldn't there be some authoritative document
:somewhere that says that this is vi? I generally found that books on
:editors (I am speaking from experience of reading books for IBM
:mainframe packages like DB2, ISPF and VM/CMS) or other vendor software
:usually for those who do not like manuals. But I like manuals, I like to
:read them from cover to cover before starting anything. I cannot find a
:good definitive manual that gives command syntax in alphabetical order
:with a good index for vi. Could you please suggest how I would go about
:ordering one? What are the manual numbers? How about emacs? From where
:can I get the manuals?
Authoritative documents are for the anally retentive. If you want that
kind of Official Statement, then you'll have to wait until the POSIX.2
group gets done with their draft. In case you didn't know, vi/ex has been
chosen as THE Unix editor. Best piece of news I've heard out of POSIX ever.
If you just can't hold back, there are what I consider definitive
documents and tutorial papers available in the BSD manuals where
everything in listed. If you haven't looked here, then that may well be
your biggest problem. There really is a book on vi -- I forget who
publishes it, because like so many things, I learned by reading the BSD
docs and then playing and prodding, only very occasionally resorting to
the source code as the final arbiter for deep questions I might have. The
only times I recall doing this were to find out what the ~ metacharacter
meant in regexps and to find (and greatly increase) the limit on macro
text (;-) and line length.
:>Post your problem, I'll post an answer.
:Here they are.
:
:1. The join should flow till the next blank line. Not just join together
:two lines. If I have the margin or some such set at say 72 cols., when I
:do a join, I have to reformat the entire para by going to the
:appropriate word (I have to judge this visually) and then split and then
:join and so on.
You should check out my Meta-f, Meta-p, and Meta-P macros I posted. (Meta
in this case means to prefix with TAB or backslash, at your discretion.
That's just how I defined my prefix key.) The basic idea is select an area
of text and pipe it through the fmt program. For example:
map = !}fmt^M
And now your = key will do what you've described. Variations on
this theme that you might like include jumping back to the start
of the current line by going prefixing that with {, or going
through the end of the file with !Gfmt.
This is an introduction to something very basic to the nature of extending
vi, and also of UNIX in general. The idea is that by using small,
interchangeable tools that do one thing well in arbitrary combinations,
this provides you with virtually infinite possibilities. This is really
important. It gives you *MUCH* more flexibilty and power than trying to
build every possible feature into every possible program. When your
escapes are to general-purpose programming languages like awk or perl,
which have such a strong bent for text processing, the possibilities
increasing wildly. Not everything needs to be built into the editor.
:2. I want to exclude some number of line from a file I am editing. Like
[text deleted]
:And if I mark the first \item line and the last \item line and exclude
:all the lines between the marks, I need to see some thing like
:\begin{enumerate}
:...............................21 lines excluded....................
:\end{enumerate}
:
:I found the above feature to be invaluable in concentrating on parts of
:the file which are separated from each other. I can do marking and go
:back and and forth. But I would never get a complete picture of the
:whole thing. This is like an overview. It will also help in matching
:paranthesis, begin ends blocks etc. There may be some automatic matching
:that can be done on vi I am sure which I surely want, but this feature
:of ISPF would be quite useful for me because I can get an overview of
:a large part of the document.
No, you can't temporarily exclude lines from your display, but I'm
honestly convinced that the fact that you want to do this is due to
contamination from other editors that try to do everything for you.
I've seen CASE tools that do this, too, but I'm not really sure why
it's so wonderful. If your program is broken up into separate files.
You can certainly select lines with the original grep command, which is
built-in to vi:
g/re/p
v/re/p
where "re" is some regular expression. v will reverse the sense.
The operation there can be arbitrary, not just "p".
You should use things like (, ), [[, ]], and % to jump around and talk
about pieces of your text. You can also mark pieces so that you can talk
about them by name. If you don't understand the basic syntax of
[count][command][target]
Where command is something like y, p, c, or !, and target is
something like ), %, $, /foo, or 23G, then you're missing out
on most of vi's power.
If you need an overview, I'd say just grep it out. Also, do you know
about ctags? It helps a lot for moving around large programs that have
been (wisely) broken up into different source files. If anyone
has a vi that still don't allow nested calls to tags, tell me,
and I'll mail you a non-proprietary, public domain module to
do this.
:3. Once you give me the above, I should be able to find say some string
:only within the excluded lines, or only within the unexcluded lines. If
:it is found in the excluded lines, those lines should be unexcluded.
:ex. /enum/x
:
:should give
:
:\begin{enumerate}
:............................... 6 lines excluded....................
:\begin{enumerate}
:............................... 7 lines excluded....................
:\end{enumerate}
:............................... 6 lines excluded....................
:\end{enumerate}
It would be nice to do :g/^\\\(begin\|end\)/p, but vi's regexps don't
understand alternation. ":!egrep '^\\(begin|end)' %" will work to
display just those lines.
:4. Is it possible to make the marks visible? Do it only when the line
:numebring is set. Like as follows.
:
: 1 This is my firts lin.
: 2 This is my second line.
: a this is line labeled a.
: 4 This is the 4th line.
: b This line is marked with b.
: 4 This is the 4th line.
: b This line is marked with b.
No, you can't, although I don't think that's how you want to show marks.
Marks on on characters, not lines. You could have more than one on a
line. I don't use many marks at one time, so they're easy to keep track
of. One possiblity would be to put the marks in reverse video, although
that still doesn't tell you what's what. I've also wanted to list what's
in each buffer.
:5. How do I get just the name of the file I am editing right now?
:Because, for example if I want to say run this file through a filter and
:save the output in a file with the same name but different extension,
:can I do this?
Just Use ":!filter < % > %.new". % is the current file,s and # is the
alternate file.
:Please by no means think that I am trying to prove that vi is really bad
:or anything, the above are somethings which I honestly like to have and
:do not have in vi, which I like more than emacs. If I have to chose
:between these two (because I am stuck with UNIX for rest of my life), I
:would like to make one of these my standard editor.
Well, according to POSIX, vi is The Standard UNIX Editor. There's
some work I'd dearly like to do on it, including adding X11 magic, but
don't see it happening in this lifetime due to other work concerns.
--tom
--
Tom Christiansen tchrist@convex.com convex!tchrist
"With a kernel dive, all things are possible, but it sure makes it hard
to look at yourself in the mirror the next morning." -merouben@math9.math.umbc.edu (Rouben Rostamian) (12/10/90)
In article <joshi.660705889@m.cs.uiuc.edu> joshi@cs.uiuc.edu (Anil Joshi) writes: >mayoff@cs.utexas.edu (Robert Mayoff) writes: >>Since you're simply trying to reflow the paragraph, use the command >> !}fmt<RETURN> >I tried to do this. I got a message that said that something like >"}fmt command not found". > >fmt in /usr/ucb which is in my search path set up in .cshrc. Any ideas >why it does not work? I also tried "}!fmt" which does not work either. This may happen if your .cshrc exits before the path is read. Many people put test of the form if ( ! $?prompt ) then exit or some variation thereof in their .cshrc to prevent unnecessary overhead in executing commands which are not needed in a non-interactive subshell. Make sure that your path is set *before* that test. -- Rouben Rostamian Telephone: (301) 455-2458 Department of Mathematics and Statistics e-mail: University of Maryland Baltimore County bitnet: rostamian@umbc Baltimore, MD 21228, U.S.A. internet: rostamian@umbc3.umbc.edu
les@chinet.chi.il.us (Leslie Mikesell) (12/10/90)
In article <110093@convex.convex.com> tchrist@convex.COM (Tom Christiansen) writes: >If you don't have fmt, it's your vendor's fault, and yours, since >the source is available on uunet. Get it. Actually, I do have fmt on at least one of the machines, but I routinely log into and edit files on many machine where I don't maintain the programs. Some of them don't even have compilers. I don't mind carting my .profile and perhaps an .exrc around, but having to install new programs just to reformat a paragraph is a bit much. >>2) How do you manipulate arbitrary rectangles of text (copy/delete/move)? >No, that's not built-in to the program. What's the application? If you >just want to swap or delete fields or columns around on the same lines, >you could easily do it from within vi itself. (Although it might be more >conveniently expressed using a more general-purpose tool.) Just because >everything is built-in to a PC program doesn't mean you should do it that >way in UNIX. If you don't build it in, you are going to have a heck of a time figuring out the piece you want to manipulate in the other tool. >The very *VERY* few times I've wanted to do something not on >the same line, it takes me maybe 15 seconds of programming in sed, cut, >awk, or perl does the trick. Show me the kind of problem you mean. It's a situation you would see in secretarial work more than programming. You have something typed in with nice alligned columns and at the last minute you decide to move one of the columns. Happens all the time. In programming, the only time you would see something like this would be in a list that initializes an array of structs, if you had gone to the trouble of visually alligning the elements in the first place. In practice, I don't need this a lot myself but it is a very good reason not to recommend vi for secretarial use. Les Mikesell les@chinet.chi.il.us
wyle@inf.ethz.ch (Mitchell Wyle) (12/10/90)
First of all, I want to thank Tom Christiansen publicly for taking up the cause of vi in this group, posting tips, tricks, macros, and documentation references, and generally being the vi proponent we need here. Maarten used to do more of this public vi defending. Thank you Tom for picking up the flag and running with it. In <110110@convex.convex.com> tchrist@convex.COM (Tom Christiansen) expounds: >Authoritative documents are for the anally retentive. Now, now, let's not be so condescending. A good reference guide is Maarten Litmath's. If you can't ftp it, I'll send it to you. This guide is better than the expensive commercial versions because it contains fewer errors. My articles in "The Sun Observer" are better than the books I have read on vi. If I ever finish my PhD, I'll write a good Vi book. The books I have read include _Vi,_The_Unix_Screen_Editor_ by August Hansen, ISBN 0-89303-928-4. It is a decent reference, but very poor for teaching beginners. It has a lousy advanced editing section. I do not recommend it. The other book, _The_Ultimate_Guide_to_the_VI_and_EX_Text_Editors_ by Hewlett Packard, ISBN 0-8053-4460-8 is better. It has more and better advanced editing features and examples. It still stinks in terms of teaching the editor to novices. Why do authors feel you have to teach ALL commands that insert, add, change, and replace ALL at the same time fer chrissakes??? >> grinn << A novice can learn to use vi in a few minutes by noting only 6 commands!!! I digress. >If you just can't hold back, there are what I consider definitive >documents and tutorial papers available in the BSD manuals where >everything in listed. If you haven't looked here, then that may well be The BSD 4.3 manuals and other collected net wizdom are available for anonymous ftp from Maarten's machine, 192.31.231.42 in pub/maart. >meant in regexps and to find (and greatly increase) the limit on macro >text (;-) and line length. I'm hacking up elvis to do this kind of thing; I have to work on dos at home :-(. >:>Post your problem, I'll post an answer. >:Here they are. >: >:1. The join should flow till the next blank line. Not just join together >:two lines. If I have the margin or some such set at say 72 cols., when I >:do a join, I have to reformat the entire para by going to the >:appropriate word (I have to judge this visually) and then split and then >:join and so on. Good point; vi needs {!}fmt built-in. Sorry, Tom; we disagree. I don't like waiting for the fork and exec or the popen(). I want my paragraph formatted by my text editor. Wordstar did it for me in cp/m. vi should do it for me also. I started writing a macro to do this, but it has bugs and I never go it to work completely. If anyone wants to add/refine, fix, here it is: map ^XF jf k0J72^V|Er^V^M map ;x {j^XF^XF^XF^XF^XF^XF^XF^XF^XF^XF^XF^XF^XF^XF^XF^XF^XF^XF^XF^XF^XF^XF It uses "f " to find a space on the current line; when it can't find a space, it exits. Otherwise, it loops forever, joining the next line, going to col 72, finding the end-of-current-word, adding a carriage-return, etc. It fails if the two lines together don't make 72 chars, and for other reasons; it is not very robust :-(. Suggestions? >You should check out my Meta-f, Meta-p, and Meta-P macros I posted. (Meta >in this case means to prefix with TAB or backslash, at your discretion. >That's just how I defined my prefix key.) The basic idea is select an area >of text and pipe it through the fmt program. For example: > > map = !}fmt^M > >And now your = key will do what you've described. Variations on >this theme that you might like include jumping back to the start >of the current line by going prefixing that with {, or going >through the end of the file with !Gfmt. I still use this method even though it's slow. I call my macro F for Format paragraph and it is usually: map F {!}fmt^M >This is an introduction to something very basic to the nature of extending >vi, and also of UNIX in general. The idea is that by using small, >interchangeable tools that do one thing well in arbitrary combinations, >this provides you with virtually infinite possibilities. This is really >important. It gives you *MUCH* more flexibilty and power than trying to yes, yes; we agree in general. You can use sort and cut to do neato stuff in vi also. However, paragraph formatting belongs to the small subset of minimal text editing a writer requires when banging in prose. Code is a different story. >:\begin{enumerate} >:...............................21 lines excluded.................... >:\end{enumerate} >: >:I found the above feature to be invaluable in concentrating on parts of >:the file which are separated from each other. I can do marking and go >:back and and forth. But I would never get a complete picture of the >:whole thing. This is like an overview. It will also help in matching >:paranthesis, begin ends blocks etc. There may be some automatic matching >:that can be done on vi I am sure which I surely want, but this feature >:of ISPF would be quite useful for me because I can get an overview of >:a large part of the document. > >No, you can't temporarily exclude lines from your display, but I'm >honestly convinced that the fact that you want to do this is due to >contamination from other editors that try to do everything for you. >I've seen CASE tools that do this, too, but I'm not really sure why >it's so wonderful. If your program is broken up into separate files. Well, you can, sort of; I put the outline at the top of the document or in a separate window (^Z and %job on a terminal). Then I can jump back and forth between the outline and the prose. The automatic parenthesis matching in vi (the % command) is invaluable for latex code with its zillions of {{{{{bs}}}}} pairs. I'd be lost without it. A long discussion of folding editors graced this newsgroup earlier this year; some people swear by them. I don't think they bring much, and I have not seen any text-editing research studies which lend evidence one way or the other. Vi uses the / command to search for text; the fact that this command is so easy to type makes SYMBOLIC movement much easier and natural. If you look GEOGRAPHICALLY for text from a draft-proof-printed page, you are working much much too hard. Jump to text by /pat, not by scrolling around!! >You can certainly select lines with the original grep command, which is >built-in to vi: > > g/re/p > v/re/p > >where "re" is some regular expression. v will reverse the sense. >The operation there can be arbitrary, not just "p". I think he wants to have an outline processor built-in. Depending on your editing style, you can implement outlining without those programs. Since you apparantly use latex, try this method: Put a \tableofcontents command into your file, something like: .... \end{abstract} \newpage \tableofcontents \newpage \section{Introduction} \label{introduction} .... Then let latex create your table of contents for you; you can hack up a printed version in red pen and bang your changes back into the editor. >You should use things like (, ), [[, ]], and % to jump around and talk >about pieces of your text. You can also mark pieces so that you can talk >about them by name. If you don't understand the basic syntax of yeah, and get away from geographical editing. Get into the habit of jumping around symbolically. >If you need an overview, I'd say just grep it out. Also, do you know and put the overview in a separate window with less(1) or vi. >:3. Once you give me the above, I should be able to find say some string >:only within the excluded lines, or only within the unexcluded lines. If >:it is found in the excluded lines, those lines should be unexcluded. >:ex. /enum/x >: >:should give >: >:\begin{enumerate} >:............................... 6 lines excluded.................... >:\begin{enumerate} >:............................... 7 lines excluded.................... >:\end{enumerate} >:............................... 6 lines excluded.................... >:\end{enumerate} > >It would be nice to do :g/^\\\(begin\|end\)/p, but vi's regexps don't >understand alternation. ":!egrep '^\\(begin|end)' %" will work to >display just those lines. Do the egrep (from a script) into a temp file and look at that temp file in a separate window. >:4. Is it possible to make the marks visible? Do it only when the line >:numebring is set. Like as follows. >: >: 1 This is my firts lin. >: 2 This is my second line. >: a this is line labeled a. >: 4 This is the 4th line. >: b This line is marked with b. > >: 4 This is the 4th line. >: b This line is marked with b. > >No, you can't, although I don't think that's how you want to show marks. Wordstar on cp/m used to have <marker> stuff which I HATED! Vi does have line-numbering mode so you could refer to lines by their numbers. Marks and buffers are mostly for cutting and gluing pieces of prose or code around in one or several files. It is not too wise to have too many of them. If you have fewer than 5, it is easy to jump around to each one til you find where you want to be. `a `b `c aha! I was coding there! I often put the text-sequence ^Mqq^M into a file to mark off where I was editing it. It's a way to save markers between edit sessions. >Just Use ":!filter < % > %.new". % is the current file,s and # is the >alternate file. as in :!cc % to compile the file without leaving the editor (to catch syntax errors). >:between these two (because I am stuck with UNIX for rest of my life), I >:would like to make one of these my standard editor. Emacs may be seductive to a new user, but after you get used to it, you'll find that holding those evil control-chars down slows down your typing enormously. Start-up time and resource hogging are two more reasons to avoid that monster. >Well, according to POSIX, vi is The Standard UNIX Editor. There's >some work I'd dearly like to do on it, including adding X11 magic, but >don't see it happening in this lifetime due to other work concerns. Yeah, I should be writing my dissertation instead of this article :-( -Mitch
wyle@inf.ethz.ch (Mitchell Wyle) (12/10/90)
In <1990Dec10.051430.12025@chinet.chi.il.us> les@chinet.chi.il.us (Leslie Mikesell) clarifies: >Actually, I do have fmt on at least one of the machines, but I routinely >log into and edit files on many machine where I don't maintain the >programs. Some of them don't even have compilers. I don't mind carting >my .profile and perhaps an .exrc around, but having to install new programs >just to reformat a paragraph is a bit much. and the fmt from uunet has BSD-isms in it, making it hard to port. Face it, Tom. If you EDIT prose, you need a fmt function in your text editor. The lisp and magic stuff are not so important, especially if you don't edit lisp! But the lack of fmt is a glaring hole in vi. >>>2) How do you manipulate arbitrary rectangles of text (copy/delete/move)? > >>No, that's not built-in to the program. What's the application? If you >>just want to swap or delete fields or columns around on the same lines, >>you could easily do it from within vi itself. (Although it might be more >>conveniently expressed using a more general-purpose tool.) Just because >>everything is built-in to a PC program doesn't mean you should do it that >>way in UNIX. > >If you don't build it in, you are going to have a heck of a time figuring >out the piece you want to manipulate in the other tool. > >>The very *VERY* few times I've wanted to do something not on >>the same line, it takes me maybe 15 seconds of programming in sed, cut, >>awk, or perl does the trick. Show me the kind of problem you mean. > >It's a situation you would see in secretarial work more than programming. >You have something typed in with nice alligned columns and at the last >minute you decide to move one of the columns. Happens all the time. >In programming, the only time you would see something like this would >be in a list that initializes an array of structs, if you had gone >to the trouble of visually alligning the elements in the first place. >In practice, I don't need this a lot myself but it is a very good reason >not to recommend vi for secretarial use. Tables: 1. Don't use vi to do tables; use sc(1). 2. If you have violated rule 1, you must resort to the regular-expression stuff in the right-hand-side of a substitute (:s) command, or else bang in the sed or awk script. In this case, given something like: 1 2 3 4 5 6 7 8 9 10 12 113 18 1012 11 1 2 3 4 5 6 7 8 9 10 12 113 18 1012 11 1 2 3 4 5 6 7 8 9 10 1 2 3 4 5 6 7 8 9 10 12 113 18 1012 11 a b c d e f g 12 113 18 1012 11 a b c d e f g 6 7 8 9 10 12 113 18 1012 11 a b c d e f g To get the columns in a different order, you could type a vi command like: !}awk '{print $3 " " $2 " " $1 " " $4 " " $5}' 3 2 1 4 5 8 7 6 9 10 18 113 12 1012 11 3 2 1 4 5 8 7 6 9 10 18 113 12 1012 11 3 2 1 4 5 8 7 6 9 10 3 2 1 4 5 8 7 6 9 10 18 113 12 1012 11 c b a d e 18 113 12 1012 11 c b a d e 8 7 6 9 10 18 113 12 1012 11 c b a d e You can make the table look nicer with the vi command: !}halign r r r r r which gives us: 3 2 1 4 5 8 7 6 9 10 18 113 12 1012 11 3 2 1 4 5 8 7 6 9 10 18 113 12 1012 11 3 2 1 4 5 8 7 6 9 10 3 2 1 4 5 8 7 6 9 10 18 113 12 1012 11 c b a d e 18 113 12 1012 11 c b a d e 8 7 6 9 10 18 113 12 1012 11 c b a d e and don't forget !}sort 3 2 1 4 5 3 2 1 4 5 3 2 1 4 5 3 2 1 4 5 8 7 6 9 10 8 7 6 9 10 8 7 6 9 10 8 7 6 9 10 8 7 6 9 10 c b a d e c b a d e 18 113 12 1012 11 18 113 12 1012 11 18 113 12 1012 11 18 113 12 1012 11 18 113 12 1012 11 fun, eh?
tchrist@convex.COM (Tom Christiansen) (12/11/90)
In article <17719@neptune.inf.ethz.ch> wyle@inf.ethz.ch (Mitchell Wyle) writes some very nice things about me. I guess my life wouldn't be complete without a cause, and I've already won plenty of perl converts this month. :-) He then goes on to catch me being reactionary: >>Authoritative documents are for the anally retentive. >Now, now, let's not be so condescending. Well, ok. It's just that to me, Authoritative Document is a little strongly worded. If Bill Joy's stuff isn't authoritative enough for you, I don't know what is. I'm not used to people asking for Authoritative Documents on UNIX with which they can judge programs to be Right or Wrong. Sounds POSIXy or DECish or IBMic, and I'm just not comfortable with it. He then goes on to elaborate on things that should or should not be built in to the editor. Yes, paragraph formatting would be a nice optimization, but you can live without it. I do not that on my little sun, it seems to take forever, which I hate, but on my Convex boxen (~18 mips per head scalar, 1/4 gig), it's nearly instantaneous. I may well be spoiled by this. >:!cc % > >to compile the file without leaving the editor (to catch syntax errors). I would point you to my Meta-l macro. I never leave the editor without having run it. It runs lint, not cc, so it's faster, plus keeps the output at the bottom of the file for further reference, and knows to delete the old stuff when putting in new stuff. --tom -- Tom Christiansen tchrist@convex.com convex!tchrist "With a kernel dive, all things are possible, but it sure makes it hard to look at yourself in the mirror the next morning." -me
tchrist@convex.COM (Tom Christiansen) (12/11/90)
In article <1990Dec10.051430.12025@chinet.chi.il.us> les@chinet.chi.il.us (Leslie Mikesell) writes: >If you don't build it in, you are going to have a heck of a time figuring >out the piece you want to manipulate in the other tool. I will stifle my urge to preach much on tool philosophy again. If you won't learn tools, you cripple yourself. Like using cc without lint. :>The very *VERY* few times I've wanted to do something not on :>the same line, it takes me maybe 15 seconds of programming in sed, cut, :>awk, or perl does the trick. Show me the kind of problem you mean. : :It's a situation you would see in secretarial work more than programming. :You have something typed in with nice alligned columns and at the last :minute you decide to move one of the columns. Happens all the time. :In practice, I don't need this a lot myself but it is a very good reason :not to recommend vi for secretarial use. "Very good" may be too strong. If you can't teach your secretary the following awkly method, you should consider replacing him with someone more trainable, since I wonder what else they can't learn either. I know, it sounds condescending again. The truth is, I've never once met a secretary whom I couldn't teach this stuff to, and I have taught a good number in my day. Now it's true that the regexp to do this is a bit awkward in vi. That's why I generally prefer to type them in on a text line first, then suck them into a buffer and execute them. :s/foo/bar/ "mdd@m and then if I don't like it, I "mP it and fix. If I do, :%& works. But that awkward part should be a hint. Use awk. You really shouldn't try too hard for nicely aligned columns in vi anyway; for this, they invented tbl. To switch columns 4 and 5 around, this is easier than the regexp in vi to do it: 1,10!awk 'print $1, $2, $3, $5, $4, $6' or using tabs because you're going to tbl it: 1,10!awk -F<tab> 'print $1, $2, $3, $5, $4, $6' I'll bet your secretaries could handle this. --tom -- Tom Christiansen tchrist@convex.com convex!tchrist "With a kernel dive, all things are possible, but it sure makes it hard to look at yourself in the mirror the next morning." -me
tchrist@convex.COM (Tom Christiansen) (12/11/90)
In article <17723@neptune.inf.ethz.ch> wyle@inf.ethz.ch (Mitchell Wyle) writes: >and the fmt from uunet has BSD-isms in it, making it hard to port. Face it, >Tom. If you EDIT prose, you need a fmt function in your text editor. The >lisp and magic stuff are not so important, especially if you don't edit >lisp! But the lack of fmt is a glaring hole in vi. "need" is too a strong word. I would say "would very much like". My fingers whip off Meta-p *really* fast, and it comes back very nearly just as fast. I wouldn't say we all *need* it. On portability, the following functions need resolution after you compile fmt.c into its fmt.o: abs fclose fopen fputc ishead perror strcpy exit fgetc fprintf index malloc sscanf strlen I assume you know that index() is how we BSD folks pronounce strchr(), so a -Dindex=strchr on the command line will fix that if your system is monolingual. The inhead() function comes from usr.bin/mail/head.c, as the Makefile directs. Just what other functions here are bothering you? If you really want, I'll be glad to post a perl solution. :-) >1. Don't use vi to do tables; use sc(1). >2. If you have violated rule 1, you must resort to the regular-expression > stuff in the right-hand-side of a substitute (:s) command, or else bang > in the sed or awk script. (Awk would seem the optimal tool for that.) Well, I would say that tbl(1) is what you use to do tables, and that sc(1L) is for spreadsheet calculation. (Note the "L" part.) But I'll murmur general agreement here. --tom -- Tom Christiansen tchrist@convex.com convex!tchrist "With a kernel dive, all things are possible, but it sure makes it hard to look at yourself in the mirror the next morning." -me
nhess@gumby.us.oracle.com (Nate Hess) (12/11/90)
In article <110110@convex.convex.com> you write: >increasing wildly. Not everything needs to be built into the editor. Of course not. That's why it's important to have an editor that's extensible. --woodstock -- "What I like is when you're looking and thinking and looking and thinking...and suddenly you wake up." - Hobbes nhess@us.oracle.com or ...!uunet!oracle!nhess or (415) 506-2650
rock@warp.Eng.Sun.COM (Bill Petro) (12/11/90)
wyle@inf.ethz.ch (Mitchell Wyle) writes: >My articles in "The Sun Observer" are better than the books I have read on >vi. If I ever finish my PhD, I'll write a good Vi book. I agree heartily! It is what I look forward to when the new Sun Observer comes out. What you might do Mitch (before you write your book :-) is just make an electronic version of your articles available (or are there copywrite problems with SO?). >>meant in regexps and to find (and greatly increase) the limit on macro >>text (;-) and line length. >I'm hacking up elvis to do this kind of thing; I have to work on dos at home >:-(. I can't wait! What would be the equivalent of dying and going to heaven would be an elvis (or clone) that would allow multiple windows/buffers on screen at the same time. Then, I wouldn't have to suffer emacs window-envy (don't suggest ^Z or buffer yank puts - I want both buffers shown at the same time) and I could have the nice comfy familiarity of my .exrc bindings. I have tried VIP mode in gnu emacs, but it is big, slow, and I don't want to have to translate all my vi bindings into .emacs lisp conventions. >I still use this method even though it's slow. I call my macro F for Format >paragraph and it is usually: >map F {!}fmt^M I have extended it a bit with this: map F {!}fmt^M}j What this does is goes to the front of the paragraph and formats it to the end of the paragraph and then positions the cursor at the beginning of the next paragraph. -- Bill Petro {decwrl,hplabs,ucbvax}!sun!Eng!rock "UNIX for the sake of the kingdom of heaven" Matthew 19:12
wb8foz@mthvax.cs.miami.edu (David Lesher) (12/11/90)
>>Not exactly, but I think I can probably do anything you would like >>done. Post your problem, I'll post an answer. >Can anyone apply? Here's mine: and mine..... I want to back up by word ends. This should be as reliable as 'b' is at backing up by word beginnings; which is to say that one-letter words and punctuation marks should not confuse it. Any takers? My favorite vi book is Sonnenschein's "Guide to vi" ISBN 0-13-371311-3 -- A host is a host from coast to coast.....wb8foz@mthvax.cs.miami.edu & no one will talk to a host that's close............(305) 255-RTFM Unless the host (that isn't close)......................pob 570-335 is busy, hung or dead....................................33257-0335
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (12/11/90)
Here's my favorite macro (like Tom's ^O):
map! ^[6 ^[o {^M.^M}^[ks
Starting from insert mode it puts in a pair of braces in my favorite
style and leaves the cursor in the middle. If you don't like two-space
indents with half-indented braces you'll have to change the macro a bit.
map ^A o $^[kJ$r 073l? ^Ms^M^[$xx0
Split a line properly at 72 characters (from the left margin), leaving
the cursor on the second half of the line and beeping if the second line
is blank. A lot faster than fmt, though on a slow connection you may not
like the screen bounce.
map ^[7c amain(argc,argv)^Mint argc;^Mchar *argv[];^M{^M}^[O
The generic program starter. I have a couple more like this to handle
other common drudgery.
map ^[7u 0/@^Mr%A@uunet.uu.net^[
How to quickly munge a To: line for dumb mailers. I actually have it
insert brnstnd@nyu.edu as well.
set autoindent autoprint noautowrite nobeautify directory=/tmp
noedcompatible noerrorbells hardtabs=8 noignorecase nolisp nolist
magic mesg nonumber nooptimize prompt noreadonly redraw remap
report=5 shiftwidth=8 noshowmatch noslowopen tabstop=8 taglength=0
noterse notimeout warn wrapscan wrapmargin=8 nowriteany
(All on one line.) I get sick of working on different configurations, so
this has all the settings I care about.
In article <109909@convex.convex.com> tchrist@convex.COM (Tom Christiansen) writes:
> set nomesg
> " because being talked to during an edit is aggravating
Oh? This is only because talkd is insane. I get a pleasant notice on my
status line when someone tries to talk.
> map! ^V^[OC ^V^[lli
That doesn't work at the end of a line.
> set modelines
Dangerous.
> " my figners have dyslexia
> ab covnex convex
> ab Covnex Convex
> ab versino version
Yeah. I'd never give up alias jbs jobs in csh, or variable Mail set to
mail.
---Danles@chinet.chi.il.us (Leslie Mikesell) (12/12/90)
In article <110178@convex.convex.com> tchrist@convex.COM (Tom Christiansen) writes: >>If you don't build it in, you are going to have a heck of a time figuring >>out the piece you want to manipulate in the other tool. >I will stifle my urge to preach much on tool philosophy again. If you >won't learn tools, you cripple yourself. Like using cc without lint. But you didn't address the point about how to pass the necessary info to the other tool. In the relevent case (manipulating arbitrary rectangles) you need 4 coordinates for the source of the block and one for the destination in the case of a move. If I have to count lines and characters I might as well just retype it in the first place. What I really wanted here was a set of macros to help with this, but perhaps even that can't be done without putting in-band markers into the text. >"Very good" may be too strong. If you can't teach your secretary the >following awkly method, you should consider replacing him with someone >more trainable, since I wonder what else they can't learn either. I know, >it sounds condescending again. The truth is, I've never once met a >secretary whom I couldn't teach this stuff to, and I have taught a good >number in my day. You've had a sheltered life. I have to deal with other people's secretaries where replacement is not an option, plus temps who already know word processing using word processing programs. I have taught some of them vi, but now that word processing programs handle everything except full regexp substitution I won't do it again. It's not a question of whether they can learn, but one of why they should spend time learning a less than optimal way to do something. > 1,10!awk -F<tab> 'print $1, $2, $3, $5, $4, $6' > >I'll bet your secretaries could handle this. Perhaps, but they shouldn't. When a tool exists that lets you mark the corners of the area and destination using normal editor motion commands and has a simple command syntax for the move, then the philosophy that says to use the best tool for the job must insist on using it. However, I didn't intend for this to become a flame against vi. I like vi for programming and uses where visual formatting is not important. I was hoping that someone would come up with a way to use vi itself to do those two operations (paragraph reform and rectangle manipulation). I do realize that arbitrary rectangle movement (slide a column down as well as over) would be pretty difficult, but perhaps someone could manage some macros for column swaps on the same line range like: :2,6s/\(...\)\(...\)\(...\)/\1\3\2/ so that you wouldn't have to count the lines and dots. Or maybe even something that would write some commands out to a tmp file and then :source it. Les Mikesell les@chinet.chi.il.us
JOANN@SLACVM.SLAC.STANFORD.EDU (Jo Ann Malina) (12/12/90)
>A novice can learn to use vi in a few minutes by >noting only 6 commands!!! I digress. I may be teaching vi to beginners soon. Which 6 are you thinking of?
nhess@gumby.us.oracle.com (Nate Hess) (12/13/90)
In article <17719@neptune.inf.ethz.ch> you write: >Emacs may be seductive to a new user, but after you get used to it, >you'll find that holding those evil control-chars down slows down your >typing enormously. Start-up time and resource hogging are two more reasons >to avoid that monster. This from a vi user who uses C-f to go forward a screenful, C-b to go back, C-d to go down half a screen, C-u to go up half a screenful... When you're typing, you don't need to use the control keys, in either vi or emacs. Start-up time of emacs is higher than vi; however, typical use of emacs doesn't involve starting it up and quitting out of it several hundred times a day, as typical use of vi does. As far as resource hogging, that is a specious argument, at best; emacs allows one to do more than vi does, so of course it will use more resources. You're conveniently not counting the time for all the fmt's, etc., you're calling from vi as part of vi's resource usage. Happy Editing! --woodstock -- "What I like is when you're looking and thinking and looking and thinking...and suddenly you wake up." - Hobbes nhess@us.oracle.com or ...!uunet!oracle!nhess or (415) 506-2650
rouben@math15.math.umbc.edu (Rouben Rostamian) (12/13/90)
In article <1371:Dec1108:11:4090@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: |Here's my favorite macro (like Tom's ^O): | | map ^A o $^[kJ$r 073l? ^Ms^M^[$xx0 | |Split a line properly at 72 characters (from the left margin), leaving |the cursor on the second half of the line and beeping if the second line |is blank. A lot faster than fmt, though on a slow connection you may not |like the screen bounce. [... other macros deleted ...] Here is the "no bounce" version of the same macro: map ^A :s/$/ /^M74^V|? ^Ms^M^[$xx0 -- Rouben Rostamian Telephone: (301) 455-2458 Department of Mathematics and Statistics e-mail: University of Maryland Baltimore County bitnet: rostamian@umbc Baltimore, MD 21228, U.S.A. internet: rostamian@umbc3.umbc.edu
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (12/13/90)
In article <4672@umbc3.UMBC.EDU> rouben@math15.math.umbc.edu.UUCP (Rouben Rostamian) writes: > Here is the "no bounce" version of the same macro: > map ^A :s/$/ /^M74^V|? ^Ms^M^[$xx0 Good idea. This is as reliable as the original: map ^A :s/$/ $/^M$r 74^V|? ^Ms^M^[$xx0 I hope the ``fmt is too slow!'' crowd is satisfied now. ---Dan
dattier@ddsw1.MCS.COM (David W. Tamkin) (12/15/90)
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) wrote in <7150:Dec1309:42:4690@kramden.acf.nyu.edu>: | In article <4672@umbc3.UMBC.EDU> rouben@math15.math.umbc.edu.UUCP (Rouben | Rostamian) writes: | > Here is the "no bounce" version of the same macro: | > map ^A :s/$/ /^M74^V|? ^Ms^M^[$xx0 | | Good idea. This is as reliable as the original: | | map ^A :s/$/ $/^M$r 74^V|? ^Ms^M^[$xx0 For both forms, why are things done the long way? Why ":s/$/ /^M" instead of "A ^["? Why "? ^M" instead of "F ", as long as that the space will be on that line? Why "s^M^[" instead of "r^M"? "r^M" works fine in my own reformatting macro. (I won't post it because it has other bugs.) Why "xx" instead of "2x"? This is a macro in one's .exrc, so saying that "`xx' is easier to type every time you use it than `2x'" doesn't count. 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
it1@ra.MsState.Edu (Tim Tsai) (12/15/90)
New question. Is there a way to get vi to recognize the cursor keys
on input mode? I was playing around with a SYS V version of vi the
other day, and noticed that the arrow keys worked during input mode!
Vi on a Sun, however, doesn't. Is this even possible (I realized
it's terminal dependent)
--
Sometimes I think the surest sign that intelligent life exists elsewhere
in the universe is that none of it has tried to contact us.
<Calvin>tchrist@convex.COM (Tom Christiansen) (12/15/90)
From the keyboard of it1@ra.MsState.Edu (Tim Tsai): : New question. Is there a way to get vi to recognize the cursor keys :on input mode? Sure, use my .exrc -- basically do this: " ARROW MACROS next four let arrows keys work in insert mode; map! ^V^[OA ^V^[ka map! ^V^[OB ^V^[ja map! ^V^[OC ^V^[lli map! ^V^[OD ^V^[i " " Who says you can't emulate emacs in vi? :-) " map! ^B ^V^[i map! ^F ^V^[lli map! ^A ^V^[I map! ^E ^V^[A " " There are probably extra-v's there cause of how i develop these, but that won't hurt anything. --tom -- Tom Christiansen tchrist@convex.com convex!tchrist "With a kernel dive, all things are possible, but it sure makes it hard to look at yourself in the mirror the next morning." -me
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (12/17/90)
In article <1990Dec14.174605.19649@ddsw1.MCS.COM> dattier@ddsw1.MCS.COM (David W. Tamkin) writes: > | map ^A :s/$/ $/^M$r 74^V|? ^Ms^M^[$xx0 > For both forms, why are things done the long way? > Why ":s/$/ /^M" instead of "A ^["? Because that will fail miserably for lines between about 72 and 80 characters. My point was to present a *reliable* line splitter. > Why "? ^M" instead of "F ", as long as that the space will be on that line? Because I wrote the macro and I don't use F. You're right, F is better so that the previous search string stays intact. > Why "s^M^[" instead of "r^M"? I've seen versions of vi where r doesn't behave properly with a newline. > "r^M" works fine in my own reformatting macro. > (I won't post it because it has other bugs.) Exactly. My point was to present a *reliable* line splitter, something that everybody could use without having to worry about bugs. > Why "xx" instead of "2x"? This is a macro in one's .exrc, so saying that > "`xx' is easier to type every time you use it than `2x'" doesn't count. On what objective basis is 2x better than xx? It is objectively worse on at least one basis: it doesn't work. Notice the $ in $xx. ---Dan
dattier@ddsw1.MCS.COM (David W. Tamkin) (12/18/90)
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) wrote in <7426:Dec1621:57:0990@kramden.acf.nyu.edu>: | In article <1990Dec14.174605.19649@ddsw1.MCS.COM> dattier@ddsw1.MCS.COM (David W. Tamkin) writes: | > | map ^A :s/$/ $/^M$r 74^V|? ^Ms^M^[$xx0 | > For both forms, why are things done the long way? | > Why ":s/$/ /^M" instead of "A ^["? | | Because that will fail miserably for lines between about 72 and 80 | characters. My point was to present a *reliable* line splitter. My guess is that it will fail if the A-ppended spaces run afoul of the wrapmargin setting. If wrapmargin is off or not in that range, it would work. But you're right, Dan: the :s form is not vulnerable to that problem. | > Why "xx" instead of "2x"? | | On what objective basis is 2x better than xx? It is objectively worse on | at least one basis: it doesn't work. Notice the $ in $xx. Fair enough. Indeed it doesn't: 2x won't function at the end of a line and 2X will delete the second-to-last and (originally) third-to-last characters instead of the last two. xx [I suppose that h2x and :s/..$//^M would work but they are comparatively inelegant] is the right way to go. Thanks for answering my questions. I still don't understand your "I don't use F." 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
mrd@ecs.soton.ac.uk (Mark Dobie) (12/19/90)
In <7150:Dec1309:42:4690@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: >In article <4672@umbc3.UMBC.EDU> rouben@math15.math.umbc.edu.UUCP (Rouben Rostamian) writes: >> Here is the "no bounce" version of the same macro: >> map ^A :s/$/ /^M74^V|? ^Ms^M^[$xx0 >Good idea. This is as reliable as the original: > map ^A :s/$/ $/^M$r 74^V|? ^Ms^M^[$xx0 >I hope the ``fmt is too slow!'' crowd is satisfied now. (BTW I am in category 4 (knowledgable user) in Tom's new hierarchy, so I can just about follow this) OK, so given that I have defined one of these 'split a line at char seventy something macros' how do I get it to format a whole paragraph. Surely I don't sit there typing ^AJ a lot. Forgive me if I am being stupid. Compliments of the season to you. Mark. >---Dan -- Mark Dobie M.Dobie@uk.ac.soton.ecs (JANET) University of Southampton M.Dobie@ecs.soton.ac.uk (Bitnet)
s-fujii@ext46.sra.co.jp (Seigo Fujii) (12/21/90)
In article <17719@neptune.inf.ethz.ch> wyle@inf.ethz.ch (Mitchell Wyle) writes: >Good point; vi needs {!}fmt built-in. Sorry, Tom; we disagree. I don't >like waiting for the fork and exec or the popen(). I want my paragraph >formatted by my text editor. Wordstar did it for me in cp/m. vi should do >it for me also. I started writing a macro to do this, but it has bugs and I >never go it to work completely. If anyone wants to add/refine, fix, here it >is: > > >map ^XF jf k0J72^V|Er^V^M >map ;x {j^XF^XF^XF^XF^XF^XF^XF^XF^XF^XF^XF^XF^XF^XF^XF^XF^XF^XF^XF^XF^XF^XF > >It uses "f " to find a space on the current line; when it can't find a >space, it exits. Otherwise, it loops forever, joining the next line, >going to col 72, finding the end-of-current-word, adding a >carriage-return, etc. It fails if the two lines together don't make 72 >chars, and for other reasons; it is not very robust :-(. Suggestions? " " format macro " \f: Format current paragraph. " Join all line in a paragraph, then do \F macro. " \F: Repeat split line 72 cols boundary. " Stop if `l' fail. " ^[F: For recursive call \F macro. " BUGS: " Need blankline each side of paragraph. " map \f {jmm}k:'m,.j^M\F map \F 72^V|lhhhElha^M^[^[F map ^[F \F -- Seigo Fujii (Software Research Associates, Inc., Japan)
asylvain@felix.UUCP (Alvin "the Chipmunk" Sylvain) (12/22/90)
In article <it1.661229215@ra> it1@ra.MsState.Edu (Tim Tsai) writes: > > New question. Is there a way to get vi to recognize the cursor keys > on input mode? I was playing around with a SYS V version of vi the > other day, and noticed that the arrow keys worked during input mode! > Vi on a Sun, however, doesn't. Is this even possible (I realized > it's terminal dependent) Someone answered this for the Sun, but here is an answer for nearly any terminal in existance. Basically, you must create a `.exrc' file and place it in your HOME directory. That file contains initialization parameters used by vi. (Note: if your SysOp has pre-configured your .profile, .login, or .cshrc file with a "setenv EXINIT" or equiv, you may want to edit the file delete that line. Copy the info into your .exrc, and you can change .exrc anytime you want. If you don't do this, the .exrc file will only take effect when you are in your home directory. Any other directory will default to the EXINIT environment.) Mapping cursor keys, or any other non-standard function key, can be tricky depending on your terminal. Most of them will produce some set of control characters, some of which you will have to `escape'. My ADM-12, for example, produces ^K for "up", etc. Others will produce a whole sequence of characters, including ESC (^[), ^A, etc. (Note the difference between `escaping' a character and the ESCape character.) Your first task is to find out what your terminal produces. Try press- ing the key while in insert mode and watch what comes out. If it leaves insert mode, you'll know there's a ^[ in there somewhere. Try pressing the key from the shell prompt, and see what comes out. You may be forced to write a quick C program that echoes the ASCII equiva- lents of it's input, but if you can't see your input from insert mode in vi, writing C code using cbreak mode is a whole 'nother chapter. If the very first character output is a control character, trying `escaping' the key. Ie, from insert mode, press ^V then your key. OK, let's assume your UP key produces the following sequence, ^[[A, or like mine, ^K. That is, for the first case, ESCape OPEN-BRACKET A, or for the second case, CONTROL-K. Here are the map commands (with exagerated white space for readability): map ^V^[[A k map ^V^K k Notice that the control characters are `escaped': That is, you enter control-V in order to be able to enter ESC. While editing the .exrc file, you will have to enter ^V from insert mode in order to enter ^V! Now, just add a map command for every cursor or function key that you want to define. Using the above technique, you can map every function key on your terminal to whatever editting function you like. This allows you to customize vi to your tastes. Examples: map the HOME key to H, which places the cursor on the top line of the screen. Map the END key to $, PAGE-DN to ^D, F10 to ZZ, SHIFT-F10 to :q!, etc. Warning: don't get too crazy, because if you need to work with someone else on their terminal session instead of yours, you'll hit one of your custom keys by habit, and strange things may happen! Then you'll have forgotten how to do the function in the original way! That can be awfully embarrassing! -- asylvain@felix.UUCP (Alvin "the Chipmunk" Sylvain) ========================= Opinions are Mine, Typos belong to /usr/ucb/vi "We're sorry, but the reality you have dialed is no longer in service. Please check the value of pi, or see your SysOp for assistance." UUCP: hplabs!felix!asylvain ============================================
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (12/22/90)
In article <5912@ecs.soton.ac.uk> mrd@ecs.soton.ac.uk (Mark Dobie) writes: > OK, so given that I have defined one of these 'split a line at char > seventy something macros' how do I get it to format a whole paragraph. > Surely I don't sit there typing ^AJ a lot. Well, I just join the paragraph with one keystroke, then type the right number of ^A's. I suppose I should make a macro for the second part, but it's never seemed worthwhile. ---Dan
ekw@world.std.com (Elliott C Winslow) (01/02/91)
I tried to map a fmt into a .exrc file on the MKS version of vi on an
MS-DOS machine, and it wouldn't escapte (^V) |. One could scream. If
someone has found the around for this, please post/mail.
Elliott Winslow IM {uunet,xylogic}!world.std.com!ekw
(914) 565-6202 {apple,pacbell,hplabs,ucbvax}!well!ekw