Date: Fri, 6 Sep 1996 10:26:28 -0700 (PDT) From: Gary Kline <kline@tera.com> To: andrsn@andrsn.stanford.edu Cc: peter@taronga.com, kline@tera.com, doc@freebsd.org Subject: Re: vi tutorial Message-ID: <199609061726.KAA12896@athena.tera.com> In-Reply-To: <Pine.BSI.3.94.960905171408.9864B-100000@andrsn.stanford.edu> from Annelise Anderson at "Sep 5, 96 06:14:21 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
According to Annelise Anderson: > > > On Thu, 5 Sep 1996, Peter da Silva wrote: > > > > Enclosed is the vi_tutorial that I've been distributing. > > > > [[ ... ]] > > There's got to be some way in every program that accepts text, whether > it's a word processor, database, or spreadsheet, to distinguish between > text to be entered into the document and text that is a command. > > This is done in Windows and many dos programs in ways that you all > know and love and that are obvious to users (so that the distinction > need not even be made)--with pull-down menus, function keys, and > Ctrl- or Alt- combinations. (Pine/pico also use this approach.) > > Emacs claims to be "modeless" because it's always in command mode-- > typing a letter or number alone is a command to insert text. In > whatever way this may be technically true, there is still a distinction > between giving a command to enter text and give a command to take some > action with regard to the program--e.g., call up another document or > whatever. > > So in vi you can call it the "entering text" command versus the command > to write the file and exit, if you like. The distinction must still be > made. Then you have to point out that once you give a command to > enter text, that command remains in force until it's cancelled in one > way or another, and after it's cancelled, other commands can again be > entered. You also have to point out that while the command to enter > text is in force, certain keys--the arrow keys--function in ways > differently from the way the function when the command to enter text > is not in force. > > Is that better or worse? (I think it might be better, actually.) > > In any event I think what's needed with regard to vi is something > oriented toward doing the basic tasks one expects of a text editor/ > word processor--entering text, formatting it, moving blocks, cutting > or copying from one file and pasting to another, saving changes, > exiting without saving changes, searching and replacing, making > corrections, reading in a file, exporting part of a file to a new > file, exiting to a shell and returning. Some of the things vi does that > most editors don't do--entering the output of a command into the text. > > In the interests of making vi more usable it may be useful to have a > section distinguishing what it is possible to do while in command > mode (when the "enter text" command is not in effect) versus what it > is possible to do while the enter text command is in effect. (Note > that there's a third "mode" in the sense of what certain keys--escape, > arrows, backspace, enter--do: the "mode" one is in on the command > line. > > A vi tutorial also needs to give some examples on useful command line > options and where one would put these to make them the default > behavior. > > The only "editor" that I know of (and I don't know about very many) > that competes with vi in functionality is emacs; I'd consider it an > open question whether it's a better use of one's time to figure out > how to make vi do these things or simply to learn emacs. Or some > other text editor. If it's not worth learning to do these things > with vi, is it worth writing about? (I think it probably is; the basics > of vi are not that difficult; what's difficult is finding the information > on how to do anything that isn't basic.) > > I would ignore history almost entirely. I would be inclined to tell > users that the version of vi running on FreeBSD is nvi, and if they > want other Unix vi's to work the way FreeBSD vi does, they have to > call nvi. > > > [[ ... ]] According to Keith Bostic, nvi is a feature-for-feature, bug-for-bug clone of vi. Which is close enough to the truth that for all reasonable purposes, vi and nvi are equivalent. Perhaps a footnote or a parenthetical comment would suffice... . You've raised some good points, Annelise--as did Peter-- about discussing the basics of vi. But which basics? Every user has his own favorite subset of vi commands and we we used every subset, the tutorial would probably defeat its purpose. Namely, of allowing new users to be able to function reasonably. Peter suggested `cw' which I use very frequently. This in the `Replacing text' section. Would `cf<character>' be overkill? Or for change to the end-of-line: `C'? Or in the deletion section, `d\<character>' Or `D' to delete from cursor to end-of-line? Other basics that I use are `o' and `O'; and `A' and `I'. And `f<character>' or `F<character>' The dot `.' to repeat-last-command. Some of these might be overkill. Ideally, this kind of overview will help users become familiar with vi. We-- I alone, or with others--can write a second piece that would, in tutorial form, give many more fine points. emacs or xemacs seems to have grown into an environment in itself. Many of my co-workers bring up xemacs and rarely bring up another xterm. You can write/code, compile, debug, re-code, recompile; send mail, read news, and probably much more that I haven't heard yet. My bias is to have separate tools for individual tasks; though this may change if I ever get brave enough! At any rate, if interested people would send me their favor vi commands, I'll toss them into the brew and then re-submit. gary
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199609061726.KAA12896>