Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!psuvax1!rutgers!otello!gear!cadlab!staff From: staff@cadlab.sublink.ORG (Alex Martelli) Newsgroups: comp.editors Subject: Re: vi for power users Message-ID: <547@cadlab.sublink.ORG> Date: 8 Dec 90 10:03:50 GMT References: <1005@langtry.cs.utexas.edu> <109909@convex.convex.com> Organization: CAD.LAB, Bologna, Italia Lines: 141 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).