Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!newstop!texsun!convex!convex.COM From: tchrist@convex.COM (Tom Christiansen) Newsgroups: comp.editors Subject: Re: vi for power users Message-ID: <110110@convex.convex.com> Date: 9 Dec 90 22:43:10 GMT References: <109909@convex.convex.com> Sender: news@convex.com Reply-To: tchrist@convex.COM (Tom Christiansen) Organization: CONVEX Software Development, Richardson, TX Lines: 178 [This article was stompted on by a phone glitch, and I forgot to recover it.] In article 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." -me