riddle@woton.UUCP (Prentiss Riddle ) (10/22/87)
T.C. Jones' program "e", which superimposes a history mechanism on vi, looks
very nice for the right application. But what would really make vi friendly
would be some sort of help feature, or better yet on-screen menus in the
style of common DOS word processing programs.
No, I don't want those features myself, but they might make vi a whole lot
more palatable to some of our beginning and non-computeroid users, who very
correctly complain about the non-mnemonic nature of vi's command set.
Powerful vi may be, but easy to learn it ain't.
Are there any cheap or free vi clones out there to which someone might feel
inclined to add such a feature?
--- Prentiss Riddle ("Aprendiz de todo, maestro de nada.")
--- Opinions expressed are not necessarily those of Shriners Burns Institute.
--- riddle@woton.UUCP {ihnp4,harvard}!ut-sally!im4u!woton!riddlebadri@ur-valhalla.UUCP (Badri Lokanathan) (10/24/87)
In article <937@woton.UUCP> riddle@woton.UUCP (Prentiss Riddle ) writes: > >No, I don't want those features myself, but they might make vi a whole lot >more palatable to some of our beginning and non-computeroid users, who very >correctly complain about the non-mnemonic nature of vi's command set. >Powerful vi may be, but easy to learn it ain't. > When somebody comes to me for help with vi, I find it very easy to describe its mnemonics, contrary to what Prentiss says: a:append c:change d:delete i:insert o:open r:replace s:substitute In fact, at least to me, this is more intuitive than emacs (no, I do not want to start another editor war, but can anybody tell me why ^X^C is more clear/intuitive/understandable than :quit in vi?) Regarding documentation, I find that often people stop at man vi, from which they learn nothing. When I needed to learn about vi features, I looked at our 4.2 docs and found nothing. Our 4.1c docs however had Bill Joy's 30 page description of vi (with Mark Horton's revisions.) I read it once and since then have had no reason whatsoever to complain about vi documentation. I have also found detailed vi documentation in all our 4.3 unix docs (not in the man pages, though :-) If taught "properly", I believe vi can be learnt in a day, since with less than 20 commands it is possible to perform many complex tasks. I am not suggesting that vi is the best editor around; however I think that most complaints about it such as lack of documentation are unfair. There is documentation for those who are willing to go to the trouble of finding it. -- "I care about my fellow man {) ur-valhalla!badri@rochester.arpa Being taken for a ride, //\\ {ames,caip,cmcl2,columbia,cornell, I care that things start changing ///\\\ harvard,ll-xn,rutgers,seismo, But there's no one on my side."-UB40 _||_ topaz}!rochester!ur-valhalla!badri
wnp@killer.UUCP (Wolf Paul) (10/29/87)
In article <1085@ur-valhalla.UUCP> badri@ur-valhalla.UUCP (Badri Lokanathan) writes: > (stuff deleted) >If taught "properly", I believe vi can be learnt in a day, since with >less than 20 commands it is possible to perform many complex tasks. >I am not suggesting that vi is the best editor around; however >I think that most complaints about it such as lack of documentation are >unfair. There is documentation for those who are willing to go to the >trouble of finding it. I believe it is a system administrator's responsibility to make sure that all documentation for a system's capabilities is available to all users, and that they BE INFORMED of its availability. A good system administrator would also have a list of additional publications (books, brochures, magazines) which people could obtain privately if they are sufficiently interested. There are many good books and manuals available, even for such "exotic" subjects as vi and n/troff, and while a system administrator obviously will not BUY all of these for every user, he should know about them and be able to suggest them to his users. Anyone interested in such a list, email me - if there is sufficient interest I will post. Wolf Paul ihnp4!killer!dcs!wnp
gwyn@brl-smoke.ARPA (Doug Gwyn ) (10/30/87)
In article <1085@ur-valhalla.UUCP> badri@ur-valhalla.UUCP (Badri Lokanathan) writes: >but can anybody tell me why ^X^C >is more clear/intuitive/understandable than :quit in vi?) First of all, I don't think anybody claimed it was. However, here is where that combination came from: There are two EMACS command prefix characters in most implementations: ESC and ^X. Presumably "X" has the mnemonic meaning "eXtension", since it extends the number of available control characters (remember, EMACS is modeless, so all commands require special characters or else entry by name after invoking a generic enter-command command). Every EMACS user quickly learns what the two prefix characters are. There is even some mnemonic logic to their typical default command bindings, since ESC is mostly used for global operations (such as word or paragraph oriented operations) and ^X is mostly used for file-oriented operations. ^C is commonly used in the DEC world to terminate processes, and many BSD users have adopted it as a SIGINT-generating key rather than the original UNIX DEL. Therefore, it isn't hard to remember ^X ^C to terminate EMACS. By the way, you can usually rearrange the bindings of control keys/sequences to EMACS editing commands to suit your personal preferences. I use many editors, including all the ones commonly mentioned in these religious discussions, and I think they all have problems. My two favorites are TECO (the most programmable) and Rob Pike's "sam" (the best user interface). But "vi", EMACS, and even "ed" are also useful; let's not pretend otherwise.