tags:

views:

37

answers:

2

I've used vi for decades, and am now practicing using vim, expecting eventually to switch to it entirely. I have a number of questions, but I'll start with the one that troubles me most. Something I have long done in vi is to type a bottom-line command into the file I am editing, yank it to a named buffer (e.g., using the keystrokes "ayy) and execute that buffer (using :@a^M). This allows me to edit complicated commands till they work right, and to keep commands that I will use many times as I work in a file. (I have in my .exrc file a mapping that reduces this yank-and-execute to a single keystroke; but that isn't relevant to my question.)

I find that in vim, I need a lot more ^Vs than in vi. This means, on the one hand, that when I have some command-line in a file that I expect to use this way, I now need to keep it in two versions, one for vi and one for vim. Also, the requirement of the extra ^Vs seems inelegant: evidently various special characters that are interpreted once when the named buffer is executed in vi are interpreted twice when its is executed in vim -- but why?

As an example, a command of the form

map =f :w^V|e foo^M

(mapping the keystroke-sequence =f to write the current file and go to the file foo) works this way in vi, but has to have the form

map =f :w^V^V|e foo^V^M

in vim. (Here in both commands, ^V is gotten by typing ^V^V, and ^M is gotten by typing ^V^M; so typing the first version involves typing three ^Vs, and the second, seven.) To be exact: the first version does work in vim if one actually types it into the bottom line (with the indicated extra ^Vs); but the latter is required in an executed named buffer.

Any explanation? Anything I can set to fix this? ("compatible" doesn't seem to do it.) Any hope that it will be fixed in a future release? (The system I am on uses version 7.0.)

(I should confess that I'm not a programmer; just a user who has become proficient in vi.)

+2  A: 

Personally, I'd stop using ^V completely. In Vim (I've no idea about Vi), there are various key notations that get round the problems you're having. For your specific example, I'd recommend:

map =f :w<bar>e foo<CR>

where <bar> means 'insert the vertical bar here' and <CR> means 'insert a carriage return here'. See:

:help key-notation

for more information. I find the <CR> much easier to understand than ^V^M.

Al
A: 

That's an interesting way of using :@, which I hadn't thought of before. I generally just use the command line history when I need to edit complicated commands, and I tend to save common or complicated commands as mappings or commands in my .vimrc (of course, I have a mapping that will pop open my .vimrc in a new tab). But there are certainly benefits to using vim's normal mode rather than command line mode for editing a complicated command.

As I understand it, you not only want to avoid so many <C-V> characters, you would also like to be able to use the same commands in vim and vi. Unfortunately, that would preclude you from using the (preferred in vim) key-notation. I think that you should be able to use the cmdline mode's Ctrl-R Ctrl-R register to help you out (:help c_<C-R>_<C-R>). E.g.

map <Leader>e mm^"ay$`m:<C-R><C-R>a<CR>
  • mm - mark cursor location so we can return later
  • ^"ay$ - yank current line into register a (ignoring whitespace at beginning and newline at end)
  • `m - return cursor to start position
  • : - enter command line mode
  • <C-R><C-R>a - place the literal contents of register a onto the command line, which seems to be where your problem with vim versus vi was coming to into play. I think that <C-R>a would give you the same behaviour you are seeing now with :@a.
  • - execute the whole thing

Using that mapping, I then typed your example of map =f :w^V|e foo^M into a file, placed my cursor on that line, ran my <Leader>e mapping, verified that your =f mapping had loaded correctly, and then ran it. Obviously you'll want to customize it to fit your needs, but I think that playing around with <C-R><C-R> will basically get you what you want.

All of that said, if you can, I'd strongly recommend taking the plunge and forgetting about compatibility with vi. Then you can use the much simpler key-notation and a host of other vim features. :-)

nicholas a. evans