Path: utzoo!attcan!uunet!mcsun!cernvax!chx400!bernina!neptune!inf.ethz.ch!wyle From: wyle@inf.ethz.ch (Mitchell Wyle) Newsgroups: comp.editors Subject: Re: vi for power users Message-ID: <17719@neptune.inf.ethz.ch> Date: 10 Dec 90 11:25:57 GMT References: <109909@convex.convex.com> <110110@convex.convex.com> Sender: news@neptune.inf.ethz.ch Reply-To: wyle@inf.ethz.ch (Mitchell Wyle) Organization: Departement Informatik, ETH, Zurich Lines: 241 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 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