Starting just today, after editing a source file for a few minutes vim suddenly responds differently to my keys than I expect it to. I don't have many details as I saved and quit lest it eat my file.
I'm concerned it could be something wrong with the keyboard on my Acer Inspire E15, but typing this post works just fine.
One thing that happened is that entering ^P (Constrol-P) pasted a word, rather than moving to the previous line.
First, Ctrl-P doesn't move to the previous line, k usually does (in normal mode).
Next time:
First, observe in what mode you are: normal, insert, command-line.
Then check any mappings, for example with :verbose nmap <C-p>. You can also list all mappings with :map | :map!
Another pitfall is if you accidentally have :set paste; then, no mappings at all suddenly apply!
Also, consider the environment: Are you in a terminal, or do you use GUI GVIM; do you have any related apps (screen / tmux, or AutoKey) that may distort key bindings? Do you connect remotely through VNC / remote desktop; these sometimes can have "sticky keys" (like Shift-Lock) wreaking havoc.
And finally, real hardware failures are very rare :-)
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?
Relatively new to VIM and having a great time using it.
One very minor annoyance I've been having is command mode character navigation when I want to revise a command. I'm used to using readline shortcuts on the regular (non-vim) command line but these shortcuts don't seem to work in : command mode.
For example, using ctrl + b to go back a character ends up sending me to the start of the line, or using alt + f to go forward a word ends up clearing the line and exiting command mode.
The only way I've found to navigate in command mode is to use the arrow keys, but I'm under the impression you should avoid the arrow keys in vim for max efficiency.
What is the standard way to navigate around in : command mode? Do vim users usually use the arrow keys here? Is there a different way to modify commands?
As a more concrete example, I've been using vimgrep a lot to search through files. I'll do a command like:
:vimgrep /font-family/j my-project/**/*.less | cope
Later, I'll want to use the same search but look for a different property, so I hit : then ctrl + p to access my previous vimgrep. Now here I have to use the arrow keys to navigate backwards to the search string and modify it. It would be much faster if I could use readline to navigate backwards by word then delete by word.
For small edits, Backspace and light use of the cursor keys should be fine. For anything larger, I would advise to use the command-line window:
In the command-line window the command line can be edited just like editing
text in any window.
So, there's no need to mentally switch to readline key mappings; just use the full editing power (including any custom mappings) of Vim!
You can switch via <C-F> from the command-line, or directly enter it (from normal mode) by pressing q: instead of :. All the details can be found at :help cmdline-window.
I like this question. Long time vim user, but new-ish here, so I can't vote it up. But indeed, perhaps unofficially, many vim fans feel that most of the time the goal is to not have your hands leave home row position (fingers move, hands relatively still).
I will admit, when it comes to command mode, I use the arrows. With P being on my pinky finger, I would miss-hit ctrl-P a lot, and it's faster to slide my right hand down (on my Natural keyboard) and find the up-arrow by quick feel, instantly, to do the same thing. Once I'm there, left-right arrows are also easy to find without looking or delay. Also Ctrl-arrows let you skip by word.
One of the great things about vim is the :help. I have easily spent tens of hours over the years reading through it, and it solves 95% of my problems if I have enough time and working-memory to push deep enough into it.
Here is what I found for :help readline:
READLINE readline.vim ft-readline-syntax
The readline library is primarily used by the BASH shell, which adds
quite a few commands and options to the ones already available. To
highlight these items as well you can add the following to your
|vimrc| or just type it in the command line before loading a file with
the readline syntax:
let readline_has_bash = 1
This will add highlighting for the commands that BASH (version 2.05a
and later, and part earlier) adds.
Give it a try! (I am using vim 7.4)
You can see a list of the default key binds with :help cmdline-history (scroll down a bit) and :help ex-edit-index.
You can remap this with cnoremap:
cnoremap <C-b> <Left>
cnoremap <C-a> <C-b>
" .. Probably more
Note that using cmap will probably get you into problems here since the right-hand side is the currently mapped action, whereas with cnoremap the right-hand side it will always use the native Vim action.
So here is my mapping:
nnoremap <cr> :nnoremap <lt>cr> :w!<lt>cr>:!tmux send-keys -t :1.1 "py.test --cov=." C-m <lt>cr><lt>cr><left><left><left><left><left><left><left><left><left><left><left><left><left><left><left><left><left><left><left><left><left><left><left><left><left><left><left><left><left><left><left><left><left><left><left>
It's pretty awesome. What it does is when I first start my vim session (or after reloading a vimrc), and hit enter, I can immediately type the name of the tmux session that I'm in and hit enter again. Assuming that I'm editing my files in the zeroth pane of window 1 and I have a tmux split (horizontal, in my typical case). Subsequent times hitting enter in normal mode will save my active file and launch my py.test tests in another window. That means that I can technically continue coding before my tests have finished passing. I forget who I first got the idea from, but h/t that guy.
Anyhow, you've no doubt noticed that there are a lot of <left>'s in that mapping, because I'd like to start the command out being able to set the session name. But there also might be cases where I'm editing my code in a different window or something, or I need to change my pytest command or something, so I still want the ability to make those modifications.
Is there a way that I can improve this mapping? Maybe by approaching it in a different way altogether?
Your initial mapping builds another mapping command, and uses <Left> to insert the cursor on the right position to complete and then execute it.
An alternative to that would be defining a custom command (e.g. :TestInSession) that takes the variable parts as argument(s). Then, your initial mapping could just build the other mapping, leaving the cursor at the end of :TestInSession, and you would have less clutter in the command-line, and easier editing at the end.
If you need the ability to re-configure your other mapping, you could define an alternative initial mapping that isn't overwritten, e.g.:
:nnoremap <Leader><cr> :nnoremap <lt>cr> ...
While vim's way of doing things is generally good, I feel like there are aspects that really get in the way as somebody who is not completely committed to vim for text-editing.
This means that I am hitting Esc+/ and typing slashes into files in Sublime Text, and hitting Ctrl+F in vim, scrolling down a page.
Similar things happen with Ctrl+S and :w and custom mapping ; to : still doesn't make it as convenient and fail-safe as Ctrl+S. Not to mention in PuTTY, Ctrl+S does something rather upsetting (it suspends output from the terminal till Ctrl+Q is pressed). Basically, IMHO some things (like switching to a "find mode" and saving the file) are good to attach to a global left-hand home-row shortcut chord rather than requiring the user to mess about in a modal command line. It simply is too often used to subject the user to these mode changes. I suppose this isnt a legitimate complaint because the entirety of vim is constructed around the modal concept, and these functionalities are a result of that.
In any case I'd like to make it a bit easier on my brain because I've tried for a while now to keep it all intact and it's simply too much (I have more or less internalized the switching between Ctrl on a windows machine on a desktop keyboard and the use of the thumb for the Cmd on my Macbook, but this modal text editor business seems to be too much). It did not take too much deliberation for me to decide that global homerow key chords are simply more intuitive.
Mapping Ctrl+S to :w is trivial, so the question here is about the find mode. I want to bind Ctrl+F to put me in find mode, but repeating it should not type slashes into the find command. Can this be done? Is there perhaps a colon-command that when executed simply drops me into the current find-command-buffer-thing?
In your .vimrc add:
inoremap <C-f> <Esc>/
noremap <C-f> <Esc>/
In whatever mode you are in, this will put you in "find" mode (it actually just types a slash in the command line which you can use to search). With these bindings it will work for all modes, even if you are in insert mode.
do you want this?
nnoremap <c-f> /
if you like you can also try
nnoremap <c-f> q/
the 2nd mapping brings you to a search history window. you could choose previous search keywords/patterns. also available to type new pattern (by pressing i)
btw, there is no find mode
Mappings can be defined separately for the different modes in Vim, see :help map-modes. This automatically takes care of your proposed <C-f> mapping: Initially, you're in normal mode, then the search pattern is entered in command-line mode.
If you so far only occasionally use Vim, and find it too "different", several things may make the switch easier:
easy Vim (evim or vim -y) defaults to insert mode
on Windows, :behave mswin and the $VIMRUNTIME/mswin.vim script create some common Windows shortcuts
graphical GVIM has menu items like Edit > Find... and toolbars.
Some things like the flow-control freeze on <C-s> in terminals are unfortunate, mostly historical accidents; you can't blame Vim for those.
You don't need to map anything. / is expressive enough and is definitely not slower than <C-f>. Same for <C-s> which, despite a certain familiarity, is not much better than :w<CR>. You are learning a new tool, remember?
What you should focus your efforts on is getting confortable with Vim's modality. The simple fact that, for you, doing a search involves hitting <Esc> is a sign that you didn't get that part. Your other comments on using Vim shortcuts in ST and ST shortcut in Vim are not good signs either and the part where you complain about having to adjust to your Mac's Cmd is the icing on the cake, IMO.
It may sound brutal but, from your question, it seems like you are doing too much at the same time, without organization and for, probably, no good reasons.
Switching from Windows to Mac OS X and switching from ST2 to Vim at the same time is sure to be confusing and I suggest you slow down a little and make a choice before you loose your mind and waste more of your time.
Which leads me to this: Why do you use a Mac and why are you using Vim?
Windows is a fine OS. Sublime is a fine editor. Even if you switch to the Mac, Sublime works very well there. So Why Vim?
If you are tired by some Sublime limitations and want the awesome power of Vim, fine. But you must wrap your head around its modality and awkwardness and accept to change your habit.
If you don't approach Vim with more flexibility, you'll never get full benefits.
If you decided to use Vim because it is trendy, I'll respectfully suggest you to stop there and go back to Sublime. Vim is weird, Vim is different, Vim is huge, Vim is a rabbit hole… if you are not ready to work with it and insist on not accepting its core design, you won't get far so why bother? You can pretty much live all your professional carreer without ever touching Vim. There's no shame in that.
Remapping / to <C-f>, on the other hand…
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.