In some moments vim works noticeably slow. When I'm in normal mode in 100 line file, type "O" (uppercase letter o) it appears about 1-2 seconds and only then above of current line new empty line is created in insert mode (that is normal behavior). And I want to know possible reasons why this happens...
I have quite powerful computer, So the problem is not in computer.
Are you hitting <Esc> then O in very rapid succession? If so, you are seeing the delay due to certain terminal escape sequences beginning with <Esc>O. Vim has to wait to see if you are actually typing one of those sequences.
To see this for yourself, in insert mode type <Esc>OA and your cursor should move up. Pressing <Ctrl-v><Up> in insert mode will show you the escape code generated.
Type :map O
If you have a normal mapping starting with a capital O, it might be possible that Vim is waiting for a timeout to be sure that you are not starting to type a complex command.
Typically, the timeout default is of 1 second.
See :help timeout and :help timeoutlen.
If you do have a mapping starting with O, you can find where it is defined with :verbose map. You can then disable it or modify it (or remove the plugin defining the mapping).
May be you have a redefined key binding that starts with "O"... so VIM must wait to see if you are going to type the following keys
Related
In my .vimrc I created the following mapping. Basically I want VIM to insert some text when pressing <leader>c.
The mapping is defined as follows:
map <leader>c iHELLO WORLD<Esc>;w<CR>
The second part of the map works (it exits insert mode correctly), but it takes about a second for it to actually go from normal mode to insert mode and insert the text.
I imagine this might be related to setting in my .vimrc. You can take a look at that here.
You probably have another mapping that shares a common prefix (<leader>c), and so Vim is waiting to see if you are going to type out any disambiguating characters before assuming you meant "just <leader>c".
You can avoid this by picking a non-ambiguous mapping, changing the other mapping, or reducing 'timeoutlen' from its default value of 1000 (ms).
To find out what the conflicting mapping might be, try :map <leader>c and inspect the output.
You must have multiple <leader>c-mappings. Vim has to wait to disambiguate for timeoutlen ms to see if you’re going to type <leader>cx (where x is anything`).
You can see your related mappings with verbose map <leader>c. Then either remove the others or extend yours to be something like <leader>ch (h as “Hello” mnemonic).
I'm using vim and the python-mode extension, but I'm having a hard time using commands that contain r. It's causing vim to replace characters instead of executing my desired command.
Here is what the vim docs for python-mode say -
let g:pymode_rope_organize_imports_bind = '<C-c>ro'
So I'm doing CTRL-cro, but like I said, it's replacing which ever character I'm under with the letter o.
What am I missing?
It seems that your mapping is not being interpreted by Vim, so it only sees the Ctrl-c, which by default aborts the current action, then the replace command r (see :help r) followed by its "argument".
You could check if the mapping is defined with :map <c-c>.
If it is correctly defined it may be that your terminal is handling the Ctrl-c directly and not passing it to Vim, as stated in Vim FAQ 20.5 - Why does mapping the key not work?. In this case you could follow the instructions on Vim FAQ 20.4 - I am not able to create a mapping for the key. What is wrong?, in special:
1) First make sure, the key is passed correctly to Vim. To determine if
this is the case, put Vim in Insert mode and then hit Ctrl-V (or
Ctrl-Q if your Ctrl-V is remapped to the paste operation (e.g. on
Windows if you are using the mswin.vim script file) followed by your
key.
If nothing appears in the buffer (and assuming that you have
'showcmd' on, ^V remains displayed near the bottom right of the Vim
screen), then Vim doesn't get your key correctly and there is nothing
to be done, other than selecting a different key for your mapping or
using GVim, which should recognise the key correctly.
When I'm in VIM insert mode, it wonderfully adds matching end characters. E.g. if I type " it will add another " immediately after the cursor. Similarly for parenthesis, braces etc. when programming.
How can I quickly skip over the inserted character, while staying in insert mode? The best I've found is to use the forward arrow key, but that's not conveniently located.
Accordingly, I either type the closing character, or I <esc>li (exit insert mode, move right one character, re-enter insert mode). This reduces the convenience of the auto-insertion quite dramatically, so I figure I'm missing something obvious.
(Note, for convenience I'm using the handy SPF13 curated collection of plugins and running MacVIM. Edit: This is the autoclose script providing the matching.)
There's basically no way to get out of an autoclosed pair that doesn't involve pressing at least one key.
The standard mechanism provided by all the autoclosing plugins is simple: type the closing character. You can also press <Right> or, if you are at the end of the line, <End>.
Maybe your plugin gives you another mechanism but you'll have to find out for yourself.
Whatever key you press, you'll still do at the very least exactly the same amount of typing as you'd do without autoclosing.
Autoclosing is not about saving typing, the only practical use of that feature is to prevent unmatched pairs. That's all and, I think, the "obvious" thing you are missing.
As you are using a SPF13 and don't know which plugins brought the mapping. There are two things that we can do
1) I usually esc followed by A. This will kept you in insert mode after the closed character if it is the last character. I usually prefer this over the second one.
2) You can circumvent the automatic closing by ctrl - v before the character, for instance ". This will not autoclose the corresponding character and you are responsible for the closing.
<C-W><C-O> or <C-W>o invoke the vim single-window command which maximizes the current vim split, and annoyingly (if you keep typing it by accident) closes all others.
I want to remap it to <C-W><C-_> which doesn't close other windows.
In .vimrc I have
map <c-w><c-o> <c-w><c-_>
map <c-w>o <c-w><c-_>
This works if I type C-W and then o or C-O in quick succession.
However, if I type C-W, then wait a second, and then type o or C-O the mappings I have set up are bypassed, and the single-window command is invoked.
Should I use some other map variation?
Another thing you can do is modify the 'timeout' and 'timeoutlen' settings:
For example :set timeoutlen=3000 will set the mapping timeout to 3 seconds instead of 1 (default).
Reference on :help 'timeout' and :help 'timeoutlen'.
The difference between mappings and the built-in two-key mappings like <C-w>o is that the former timeout, whereas the latter wait indefinitely for the second key press. To completely override the behavior with a mapping, you'd have to define an (expression-) mapping for <C-w>, and handle the second key inside the mapping with getchar() (which also waits indefinitely).
But please think carefully whether such effort is really needed: If you're prone to fat-fingering keys or pressing the wrong ones, your use of Vim will be severely hampered. Better learn through the quick feedback that you've pressed something wrong, and try to work on improving your muscle memory!
How about putting set hidden into your .vimrc, so after closing all the splits they don't get closed, only put to background? After that you can list all the opened buffers via :ls command for example.
But regards to your mapping, maybe you could try unmapping (or yet even better nunmap - which unmaps a command only in normal mode) o first, and then map it.
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.)
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.
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. :-)