Date: Thu, 5 Sep 1996 18:14:21 -0700 (PDT) From: Annelise Anderson <andrsn@andrsn.stanford.edu> To: Peter da Silva <peter@taronga.com> Cc: kline@tera.com, doc@freebsd.org Subject: Re: vi tutorial Message-ID: <Pine.BSI.3.94.960905171408.9864B-100000@andrsn.stanford.edu> In-Reply-To: <199609051126.GAA09077@bonkers.taronga.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 5 Sep 1996, Peter da Silva wrote: > > Enclosed is the vi_tutorial that I've been distributing. > > Mind if I make a couple of suggestions? They're pretty deep changes, > but I think are important to really understanding VI. You have almost > certainly internalized these pieces of information, but you haven't > concretized them, perhaps. > > First: drop all mention of "insert mode" and "command mode". Why? > Because "insert mode" doesn't really act like a "mode". It acts like > a "command". If people think of an insertion operation (i, a, o, and > so on) as being a command "itexttexttext^[" then things that just > seemed like quirks of vi suddenly make a lot of sense. 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. > > Second: don't dwell so early on the shortcut commands. Teach the > basic moves and combinations (dw, cw, and so on) and then mention > things like "ZZ" and "~" as asides. If you learn the basic command > structure before even seeing the shortcuts and special cases it'll > really be a lot easier. > > (also, ZZ is a shortcut for :x^M not :wq^M) Agreed--I'd also minimize "basic moves" and go for doing tasks. Annelise
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSI.3.94.960905171408.9864B-100000>