[Fwirt]

I started writing a more fleshed out vi compatibility mode for TextAdept earlier this year. As someone who understood the basics after going through :vimtutor multiple times but always struggled with the more "advanced" commands, there's no better way to actually grok vi than to just try to recreate it. It's pretty amazing how much Bill Joy managed to pack in. Of course, if you're implementing POSIX vi, there are quite a few features that have aged poorly, like roff/troff macros and line-editing, but there are also quite a few commands that I had never paid attention to (like _) that have subtle behaviors that sped up my editing even more. The hardest part about becoming proficient in vi is committing commands to muscle memory so you don't habitually fall back on hjkl.

[rav]

> Of course, if you're implementing POSIX vi, there are quite a few features that have aged poorly, like roff/troff macros and line-editing

What do you mean by "roff/troff macros"?

EDIT: Ah, you're probably talking about the "section-wise" movements, defined in POSIX with language like "A line whose first character is a <period> and whose second and third characters match a two-character pair in the 'sections' edit option (see ex)" - that's the first time I've stumbled upon the 'sections' and 'paragraphs' options in the Vim manual ... Very quaint!

[Fwirt]

Yep, those are the ones! There's also the oddity of the [[ and ]] motions. In the POSIX standard, those are the only two-character motions. I was using a state-machine to implement motion commands, and that single command threw a wrench in the works. Of course, vim took two character commands and ran with it, so in vim [ can be followed by a whole host of characters that all do different things. Since g was not mapped in vi they also did the same thing there.