Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!microsoft!steveha From: steveha@microsoft.UUCP (Steve Hastings) Newsgroups: comp.editors Subject: Re: vi Alternative Required (long posting) Message-ID: <59763@microsoft.UUCP> Date: 12 Dec 90 19:26:30 GMT References: <1616@ukpoit.co.uk> <109752@convex.convex.com> <1005@langtry.cs.utexas.edu> Reply-To: steveha@microsoft.UUCP (Steve Hastings) Organization: Microsoft International Products Group Lines: 215 In article joshi@cs.uiuc.edu (Anil Joshi) writes: > >mayoff@cs.utexas.edu (Robert Mayoff) writes: >>vi is my favorite editor, but it is not for everyone. I love vi because of the >>speed it offers. vi, in general, offers the best response time I've seen, and > ^^^^^^^^^^^^^^^ I love the speed of vi, and as a touch-typist I love the keyboard layout. >Compared to emacs (are there any choices in the UNIX world for editors >other than vi and emacs? I am not asking for developing a new one. But >does there exist an editor other than emacs/vi?) Other editors exist, but vi/emacs are the most common. You might look into Microsoft Word for XENIX, a product of the Santa Cruz Operation (SCO). It wants a 386 UNIX (preferably SCO UNIX 386, of course). >>eliminates the problem of taking my hands off the home row. I freely admit > >Then why don't the real typist/secretary types like this editor? What >does UNIX land has to offer to these people? I have met typist/secretary types who like vi, but they are few. I suspect it is because most people don't prefer modal editors. The lack of training may have something to do with it, too, and the secretaries probably want good manuals. Another problem is that vi is not a word processor. It is a text editor. While it is more efficient in terms of machine resources to split the two functions, like vi and troff, human resources are much more important than machine resources. vi is *not* a good solution for someone who needs a word processor -- for example, a secretary. >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 a number of such manuals for vi. I prefer the "research papers" that I already have, so I can't give you a title or author, but I saw a very good book that explained vi in great detail, including how to use common UNIX tools with vi. Check bookstores, or this newsgroup. >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? You can do some tricky things with yanking text into buffers to build a command, and then using the @ command to run the command in the buffer. But I never do that. I don't have any macros with parameters, and so far I don't miss them. >can I run some other .exrc like file from inside the editor? :source filename >I do not have anything against reg.exps. The real problem is the >insistence that what ever one has to do should be done only through >reg.exps. There are other ways of doing this stuff. This like the >history command in C-Shell. If you want to change even a teeny-weeny >little character somewhere in the middle of the previous command, you >start with a reg.exp. substitution. ^foo^bar will change a teeny-weeny little character in the middle of the previous command quite conveniently. Just make sure that you have enough context in front of the character that it is recognized. Example: % vi bif_long_hairy_filename # Oops % ^if^ig # Fix it vi big_long_hairy_filename # csh echoes and runs the fixed command > Don't you think it would much >simpler just present the command in the input buffer and let the user >change the portion he/she wants through cursor keys, spaces, delchar key >etc. I do not understand this comment. The C Shell history mechanism was designed for paper teletypes, and is therefore line-editor oriented. The Korn shell has what you want: it uses either Emacs or vi emulation to edit old commands. But this has little to do with vi. Your complaint about regular expressions does not pertain to vi, though. vi offers about six ways to do anything, and does not require any use of regular expressions. Try this some time: :g/foo/o This will find every line with "foo" in it and run vi in open mode on each such line. (You hit 'Q' when done with each line, to see the next one.) Then you can use standard vi commands to fix up the line any way you like. You can also just do this: /foo, then fix up the line as you want it, then hit 'n' for the next "foo" in the file. By the way, if the edit is very simple, you can often just hit the '.' key to repeat it. ('.' repeats the last single command in vi.) If you or your users don't like regular expressions, :set nomagic >>probably). Another feature about vi is that the user can pipe parts of a file >>through a filter. > >I want to do this. I have not yet figured out how I can pass a part of >the file through a filter. I know how to do this for the entire file >though. If you want to pipe part of a file through the filter, and replace that part of the file with the result, use the '!' command in vi mode. Example: sort lines. The '!' command works like the 'd' command in that once you type it, it waits for you to give it any movement command to tell it how much to work on, and as a special case "!!" works on a whole line. So: !Gsort # pipe the rest of the file through sort 20!!cat -n # number the next 20 lines (starting at 1) mb # mark a line with the letter 'b' # go to some other line with any movement commands !'bsort # sort all lines from the marked one to the current one !}fmt # pipe the next paragraph through fmt (reformat paragraph) # note that vi has naive ideas about what a paragraph is If you want to pipe a copy of some lines through a filter and see the result, you use the "w !" command, like this: :w !spell # check spelling on the whole file :'b,'ew !spell # check spelling on the lines from mark b to mark e :2,36w !spell # check spelling on lines from 2 to 26 If you want to read in the output of a command, do it like this: :r !ls # put a directory listing in the editing buffer >I agree with you entirely. An editor should be the fastest piece of >software because that is the primary link between a programmer and the >computer. This is why no other editor has replaced vi for me. >Am I wrong in assuming that >they have been basically developed by some grad. students? I also have a >feeling that some of the computer science hacks are too caught up in >their own little hacking tricks like named pipes or whatever and >sneer at the users. Do you think that they would care too much about the >poor typist/sceretary who has to use these tools? Now, on the otherhand, >if they were to make money, they would put everything they have got into >it. The popularity of emacs arises from it being a free-bee package than >anything else. If one was paying some good $s for it, one would demand >more. IBM sells ISPF for real $s and they spend enough money on >research and continually improve their products. This is true with any >company (be it Apple or DEC etc.). This is a spurious argument. vi was written by a graduate student, true, and the results reflect his ideas about what is a good editor. His ideas mesh well with mine, so I like the result. On the other hand, IBM Display Write is one of the worst word processors available, even though is is sold for real $s and there were continual improvements made to it. (I read in PC Week that IBM is scrapping Display Write and that the next version of Display Write will be a XYWrite OEM version.) The people who like Emacs are the ones who like to be able to radically rearrange the user interface, and use their editor to read their mail, run their shell commands, and so on. There are many, many features available in Emacs. I prefer a lean, mean editor like vi, but the people who like Emacs aren't stupid and aren't just using it because it is free. >There is a problem. Keys cannot be redefined. But it is not such a big >deal. I consider a lack of macros to be a grave deficiency in an editor. Most of my macros are dirt simple, but they save so much typing I don't want to live without them. >You are totally wrong in this. Character-at-a-time terminals use old >technology. They are the ones who do not have any sizeable buffer. If >the OS (or some OS process) doesn't take it off its hands, the >characters are lost. Every time you press a key, the entire interrupt >sequence is invoked. I'm not sure I buy this. You can have a stream-oriented terminal with buffering, and it is possible to have an I/O system that handles the keystrokes without interrupting the main CPU. Have you ever heard of I/O processors? > Ever wonder why UNIX editors are so slow? vi isn't slow unless UNIX is slow. There are some inefficiencies when you have to send and receive escape sequences, but these are generic to any terminal-based software. vi on the console is *really* fast. >Yes I am screwed. I am stuck with vi and/or emacs and dumb esprit >terminal which shows only 24 lines. Sounds to me like you would want to get Emacs. Anything Emacs does that you don't like, you can fix by rewriting the macros. You won't get blazing speed, though, unless you use vi. And if you use vi a while you might even get to like it. -- Steve "I don't speak for Microsoft" Hastings ===^=== ::::: uunet!microsoft!steveha steveha@microsoft.uucp ` \\==|