Submit Hint Search The Forums LinksStatsPollsHeadlinesRSS
14,000 hints and counting!


Click here to return to the 'Uh, actually...' hint
The following comments are owned by whoever posted them. This site is not responsible for what they say.
Uh, actually...
Authored by: CarlRJ on May 12, '04 04:28:16PM

I've used both nvi and vim (along with various earlier incarnations of vi) for a very long time, and I have to say, nvi is one I really try to avoid, because I've seen it corrupt data in a number of circumstances. In particular, filtering large blocks of text (e.g. "!Gsort") will sometimes mangle large sections of text (replacing them with nulls or garbage), and recovering files (e.g. "vi -r filename" after a network connection drop) often doesn't work (i.e. brings up an nvi session that core dumps the moment you try to do anything with it). So, use at your own risk.

Note that vim's behavior can be substantially modified by tweaking its configuration in ~/.vimrc to make it variously more, or less, like traditional vi (adding "set compatible" to one's ~/.vimrc will ensure you get the more traditional experience). As I said, though, I've been using various flavors of vi for a very long time, and vim is by far the best I've seen; I strongly encourage you to try exploring vim a little -- some of the changes take a little getting used to, but it really grows on you. I cringe a little when I have to use other versions of vi now.

Also, I would strongly suggest not removing files from the Apple-provided distribution (which a Software Update may fiddle with at any point), especially when all you want is to control which program gets run for a particular name. The historical Unix way of handling this is to ensure that /usr/local/bin appears earlier in your $PATH than /usr/bin, so your replacement version of vi in /usr/local/bin will be found before (in place of) the system's version in /usr/bin. The other common tactic is to symlink the preferred version into your personal bin directory (i.e. "ln -s /usr/local/bin/vi ~/bin/vi"), since ~/bin should always be near the front of your path.



[ Reply to This | # ]
Uh, actually...
Authored by: gruntfuggly on May 13, '04 04:43:28AM
The one thing I can't get vim to do which I would really like is for the insert mode to quit when I use an arrow key. I've got an environment variable (EXINIT) which contains a load of key mappings which work a treat with older versions of vi, but vim seems to ignore the 'escape' code in it. This is what it looks like:
setenv EXINIT 'map ^[Ox -| map! ^[Ox ^[-| map ^[Or +| map! ^[Or ^[+| map ^? X| map! ^[OD ^[h| map! ^[OC ^[ll| map! ^[OA ^[k| map! ^[OB ^[j| map! ^[[5~ ^B| map! ^[[6~ ^F| map! ^[OP ^[| map! ^[Oq ^[G| map! ^[[1~ ^[/| map ^[[5~ ^B| map ^[[6~ ^F| map ^[OP ^[| map ^[Oq G| map ^[[1~ /| map ^[Op i ^[| map! ^[[4~ ^[mz| map ^[[4~ mz| map! ^[[2~ ^["zP| map ^[[2~ "zP| map! ^[[3~ ^["zd`z| map ^[[3~ "zd`z| map! ^[Om ^["zy`z| map ^[Om "zy`z| set showmode| set shiftwidth=3| set ignorecase| set tabstop=8| set noslowopen| set report=1| set autoindent| set exrc'
Can anyone give me a way of making vim behave in the same way?

[ Reply to This | # ]
Re:Uh, actually...
Authored by: riceran on May 13, '04 12:11:49PM

That is precisely what the .vimrc, as mentioned above, is for. Just include your map commands in the vimrc, though your syntax will be a bit different than for your environment variable. I am pasting several of my mappings (just as they appear in my vimrc) below. It should be noted that <ESC> is actually what you type (literally) where you want an escape character. Same thing with <CR> for a carriage return. The syntax of <C-x>, where x may be replace with any letter, is what should be entered in order to obtain a control-ed character. There are similar <somethings> for the arrow keys and such.

map <C-S> :%s/\s\+/\t/g<CR>:%!align -s t<CR>

map <Leader>s <Esc>:!aspell -c --dont-backup "%"<CR>:e! "%"<CR><CR>

nmap <TAB> <C-W><C-W><C-W><C-_>



[ Reply to This | # ]