Look, it's really not that tough. Here's what you need to treat vim as a text editor with syntax highlighting:

  esc (escape) = go to the default mode
  i (insert) = when you want to make changes to the document
  
  esc + : (escape, colon) = think of this as control + whatever
  :w = (w)rite - save your file
  :q = (q)uit - quit vim
  :wq = (w)rite, then (q)uit
  :q! = (q)uit!, discarding any changes

Just those few things will let you use vim well enough while you're figuring out all the really cool stuff it can do.

Emacs can be treated similiarly: C = control M = "meta", usually the alt or option key. You can use escape if you want.

  C-x C-f = control x (do something) + control f (find file) - open a file
  C-x C-s = save a file
  C-x C-c = quit
  C-k = (k)ill - this is similar to cut
  C-y = yank - this is similar to paste

For emacs, it may be easier to start with cua mode -

  M-x cua-mode 
  (btw, m-x means "run this function") 

Cua mode gives you a copy, cut and paste that works the same as your operating system.

You're replying to the wrong person - vim is my primary editor. I'm ranting about the stupidity of the phrase "Steep learning curve."

heh, I guess I misread what it was you were ranting about; I took it to mean that you hate any sort of learning curve when it comes to editors. Thanks for clarifying!

You left out hjkl and C-bnpf, the cursor. And / and C-s, search. These are the only things I know in vi but it makes it barely usable for config.

If you're using vi/vim for real programming, you'll want to know about tag searching as well - it's one of the better ways to deal with multi-file source code. In both nvi and vim, control-] jumps to the tag under the cursor, and control-t pops back to the previous context. (You'll need to run a program such as ctags on the source to create the tag index first.)

The commands you demonstrate are not going to convince anybody that Vi(m) is a great editor. Not at all.

I'm not trying to convince anyone; I'm pointing out that you can get started with basic tasks without having to know a ton of commands.

I think it means that there is a lot of stuff you need to learn all at once, upfront, before you can really use vi effectively. It's in contrast to being able to just learn a few basics and pick it up gradually. The steepness of the learning curve doesn't have anything to do with how long it takes overall.

The phrase originally meant easy to learn with diminishing returns after a certain point, for exactly the reasons you suggest. However, the phrase "steep" implies something hard to do, so the phrase gradually lost that meaning and gained the opposite. I fear the same fate for the word "nonplussed." "Unique" is already half dead and is migrating to a synonym for "unusual." The subjunctive tense is huddled in its bunker somewhere, wishing it were more popular. The pluperfect feels secure now, but its day will come. Its day will come, friend.

The phrase "steep learning curve" means hard to learn, or with a lot of stuff to learn, not anything to do with time (except as it takes more time to learn more, I guess). The graph is of usefulness vs amount learned.

I always thought that productivity was on the X-axis and the cumulative summation of effort was the Y-axis, and the steepness of the curve was about the large size of the derivative. But now that I write it all out, that is probably too much math to attribute to a common phrase.

I've never associated a "steep learning curve" with the time it takes to learn, more that there is quite a bit of knowledge that is needed to have a baseline proficiency in it. I suppose that would put Usefulness/proficiency on the Y-axis and knowledge on the X.

Nope, that's still the wrong way round. If "usefulness" is Y and "knowledge" is X, and you needs lots of knowledge before it's useful, then the curve is shallow.

I see it something like: http://www.wolframalpha.com/input/?i=Plot[%28Sqrt[Pi]+Erf[3x...]. At first, you can use it and get something done, but it isn't useful. As you learn more, it becomes slightly more useful, but not much, until it hits a point where you finally understand the interface, and can use the features to their complete intent.

Having thought this through a little more, it seems more like bumps. For example, you can't do anything with Vim until you learn basic motion and insertion. That a bump. Then, you learn how to use the more complex motions, and get another bump. With something that has a steep learning curve it is done in bumps, rather than being smooth, because partial knowledge doesn't help any. If you think about it, if you only know the j and r commands in vim, you're not going to be doing anything at all, you're going to need to know at least hjkli before you can even use it.

I've decided that "steep learning curve" doesn't have to do with mathematical graphs at all. Saying something has a steep learning curve is the same as saying there is a barrier to entry. That barrier is knowledge, and a steep path over that barrier indicates a lot of of basic knowledge is necessary to get past the barrier.

I don't think "takes a long time" is necessarily right - learning vim in an adjustment, you can make that adjustment over a long or short period. Also, that adjustment will be easier if you are looking forward to the advantages it can bring.

It ought to be the contamination of the mental images of a graph and a steep hill (which is hard to climb).

Neither a pedagogical nor an intuitive analogy -- but fun!

Since I don't write parsers for natural languages, I like that kind of expressions more than they irritate me.

vi fans might think that is related to me prefering emacs... :-)

Edit: Grammar, spelling. Sigh.