I use FuzzyFinder in VIM (cannot switch to Command-T, no Ruby support on my server). It works well, except for one issue: Whenever I hit backspace (for example, after making a typo), the entire FuzzyFinder buffer just closes.
This doesn't happen every time, only right after entering a directory. For example:
FILE>filename -- I can hit backspace just fine, and get FILE>filenam
FILE>folder/ -- if I hit backspace now, the buffer just closes. It's as if I can't navigate backwards in the hierarchy after entering a directory.
I have no idea why this happens, and it's driving me crazy. Any advice would be appreciated.
This also happens when I press Ctrl+w as it says in the fuf documentation.
I've been using FuzzyFinder for a while and never faced this problem.
Possible you have some mapping that may be interfering with FuzzyFinder. You could try :map <bs> to find out if there is any mapping on backspace key, and :10verbose map <bs> to find out where such mapping was set.
You also could try :unmap <bs> and :unmap! <bs> to remove any mappings from backspace and check if the issue still exists.
If the above doesn't solve the problem you might consider contacting the plugin author, as the issue could also be related to some other mapping, as stated on FuzzyFinder changelog, :h fuf-changelog:
- Fixed the bug that it did not work correctly when a user have mapped <C-p>
or <Down>.
Related
Lately, when using Vim in tmux over ssh, sometimes something happens where Vim starts ignoring all my mappings that start with Ctrl: for instance <C-P>, which I have bound to the CtrlP plugin. Instead, Vim runs the builtin action (in this case, moving lines upward in the file). I don't doubt that the correct keypress is reaching Vim, as it uses the correct builtin action associated with <C-P> (using :send-keys to send ctrl-p from tmux also causes the builtin <C-P> in vim to run, instead of the mapping).
All my mappings not involving the control key still work. For instance, I can do this:
nnoremap p :echo "test"<cr>, and pressing p echoes test
But then immediately after,
nnoremap <c-p> :echo "test"<cr>, and pressing CTRL-P doesn't echo test, it moves the cursor up one line.
Restarting Vim always fixes the issue, but at some point, something I do causes the problem to surface again. I've been working mostly in tmux through ssh lately, so I'm not 100% sure if either one of those are the problem (although I think I recall this happening once in Vim in tmux not over ssh), but as mentioned above, I believe using send-keys directly from tmux as a test is ensuring that vim is getting the actual ctrl-p keycode. As well, <C-V><C-P> in insert mode does actually insert ^P.
Note that although I've used ctrl-p here as an example, since it's a key I actually use a lot in practice, this applies to any control key mapping.
Is there some kind of Vim state I don't know about that's causing this to happen? Is this likely a terminal problem? What are my next steps?
Whenever I hit the minus key (-) while in :Explore mode to go up dir there seems to be an extra <SPACE> character being added somehow.
The issue comes in when setting <SPACE> to map to <PageDown> which unexpectedly causes navigating up a directory to jump down a page. I've removed everything except :map <Space> <PageDown> from my .vimrc to try to narrow down the issue and to see if a plugin or setting was the cause. I'm using NVIM v0.4.2 installed using Homebrew.
I've used a similar setup on other machines in the past without this behavior and can't seem to pinpoint what I might be doing differently.
Thanks in advance!
Well, that sent me on a merry chase. I could be wrong, but I think there's a bug in netrw:
if !hasmapto('<Plug>NetrwBrowseUpDir') |nmap <buffer> <silent> <nowait> - <Plug>NetrwBrowseUpDir |endif
See that space prior to |endif? I think that's getting sent along with the plugin command. I'll submit a patch, but in the meantime you could add this to your .nvimrc or init.vim:
nmap - <Plug>NetrwBrowseUpDir
making sure there is no stray space at the end of that line!
I freshly installed Ubuntu 16.04 and then I installed vim. Soon I realized that Ctrl + O which I regularly use in vim to jump to the last place, does not work! After some search, I got the following commands:
:nnoremap <M-Left> <C-O>
and
:nnoremap <X1Mouse> <C-O>
I tried putting both these in my .vimrc but they don't give me the desired effect. I am really annoyed by this since this is one of the most used things that I use. What am I missing?
Edit: I reinstalled vim from scratch, also deleted the ~/.vimrc file. After deleting the file, I checked for /usr/share/vim/vimrc; it was there. Then I installed vim and tested for Ctrl+o; it works till I close the file. However, after I open it back, it forgets all the history.
Well, the actual answer as mentioned in the comments is your vim config files didn't have proper permissions on them. In addition to that, the key mappings you used in your question are invalid according to the docs:
:help X1Mouse
The X1 and X2 buttons refer to the extra buttons found on mice.
The 'Microsoft Explorer' mouse has these buttons available to the right thumb.
Currently X1 and X2 only work on Win32 environments.
And
:h M-Left
Alt-Left Move cursor to the beginning of the previous word
M = alt.
Put this in your vimrc. Enable the mouse first:
set mouse=a
map <LeftMouse> <c-o>
Although Vim uses inefficient gluing of movements together if you want to get to a far away arbitrary place on the screen, which the mouse solves well and much faster than Vim :)
Note:
This is a plugin-induced problem, but it happens with multiple plugins and it does not happen in MacVim.
Problem:
When hitting Backspace in Insert mode while using a plugin which handles automatic closing of brackets, quotes and such (delimitMate, vim-autoclose), the cursor turns into a block while deleting the character (this happens faster than I can blink my eyes but remains one of my pet peeves on terminal Vim), giving the impression of a tiny flash, which on every deletion of a character becomes annoying.
I presume it leaves Insert-mode to perform an normal/ex command), due to the remap done by the plugins, and I can confirm that this "changes to block and back"-flash does NOT happen with the plugins disabled.
The mapping for each of the plugins is as follows:
delimitMate
:verbose imap <BS> => i <BS> #<Plug>delimitMateBS
vim-autoclose:
:verbose imap <BS> => i <BS> *#<C-R>=<SNR>44_Backspace()<CR>
This problably means nothing as I'm not posting what the invoked functions actually do, it's just meant to show that Backspace is being remapped.
You're probably eager to point me to the issue tracker of each specific plugin at this point, but like mentioned earlier, this issue does not happen in MacVim. Perhaps it does, perhaps it's simply happening too fast for my eyes to see, but while using MacVim, there is absolutely no visible cursor change/flash.
These disappear if I do a page-up and page-down. Why does this happen and how do I rectify it?
http://i.stack.imgur.com/DnMYl.png
I recently fiddled around with my vimrc. Could that be the cause?
UPDATE:
I figured out the cause. I had added to functions that automatically updated the cwd name and the current git branch in my vim statusline. This caused vim to be laggy and everytime it lagged on a up/down/left/right key hit, it printed out the ghost characters ^[OA, etc.
It's possible that stuff got complicated because I was using vim in tmux, but I saw the ghost characters outside tmux also. So, probably not.
I've turned off those two functions in my .vimrc and my vim statusline is presently less awesome than it used to be :(
Wish there's a way out.
^[OB and ^[OA are how your terminal represent <down> and <up>.
I've seen these (and their friends ^[OC and ^[OD) appear in the "command line" or omni-completion menus and during usage of a couple of plugins in vim in tmux.
My solution was to map them to the directional keys:
map ^[OA <up>
map ^[OB <down>
map ^[OC <right>
map ^[OD <left>
In case you don't know, you must not type ^[ as two characters, you must do <C-v><Esc>.
That is, while in --INSERT-- mode press the Control key and the V key together then hit the Escape key. Doing so will input the correct single character that looks like ^[.
This issue is discussed at length on the Vim Wiki article. There seem to be multiple causes, I personally encountered this issue when running vim under tmux.
A solution from there that worked for me and seems less hacky than mapping the keys was the following config:
set term=cons25
Hard to say without knowing what's in your vimrc, but you can confirm whether it's something in there by starting it up without running it and seeing if it still happens using the following...
vim -u NONE
Do you happen to be using zsh? I had this issue with vim + zsh/oh-my-zsh. Moving back to vanilla bash solved this issue (amongst others) that I was having with vim.