Smething just happened in the last 20 minutes or so to my vim. I must have hit something, but I can't figure it out, and nothing will get it back to the 'real' behaviour.
I've always used : to jump to a line number. Now, when I hit : then a number - (1-9), vim instead goes in to "insert" mode and inserts a letter. (1=q, 2=r, 3=s, 4=t, 5=w, etc.)
Trying to search around for this is worse than looking for a needle in a haystack!
Any ideas as to what sort of secret "mode" I've enabled? And better yet, how I might get back to normality?
Thanks!
Not sure what you've done there but you can also jump to a specific line number by entering the line number and then hitting G (Shift+g).
Shift+g on its own will take you to the last line of the file.
It could be your shell and not VIM. If restarting VIM doesn't fix your problem, try opening a new shell and using VIM there. If nothing works, move your .vimrc file and any shell start ups out of the way (by renaming, not deleting, of course), open a new shell, and VIM. If that doesn't work, try a new keyboard. :-(
Closing and opening vim should reset whatever you funky mode you've discovered. If not, you've got something profoundly weird going on -- vim doesn't store settings that are turned on while in the file.
BTW, you're totally ruining my "vim doesn't break" meme.
Well, I've no idea what it was, but rebooting the computer - Macbook running leopard - seemed to work.
I'd tried new shells to no effect. I just didn't want to have to reboot.
See - macs have problems too! :(
Thanks for all the quick responses from all y'all. Hopefully I won't have to figure that one out again.
Related
I am using vim with Pymode to write python source code. I have the come across some strange behaviour which is intermittent but very annoying.
If I am in insert mode and type a full stop (e.g. self.method()), whilst typing self vim prints at the bottom
-- Keyword completion (^N^P) The only match
As soon as I type the full stop vim seems to freeze momentarily, then
-- INSERT -- appears at the bottom, but my cursor is now on the full stop, so that when I write method() it actually appears behind the full stop. I keep having to go back and move the full stop.
I can't figure out when it happens and when it doesn't, when I open a new file it doesn't happen straight away.
Any ideas on what may be causing this? I have only noticed it recently.
This is a problem caused by some combination of pymode and rope. Either way putting
let g:pymode_rope_lookup_project = 0
in your vimrc solves it apparently. See here for the pymode issue.
I have been bothered by this problem for a while, which affects gdb, bash, gnuplot...etc, almost anything that uses readline. (Surprisingly, csh works without any problem).
The problem is that the backspace would delete a whole word instead of a character. I modified the ~/.inputrc file and after C-x/C-r, it correctly deletes one character. However, after enter is pressed (either to run a command or just starting a new line), the setting in inputrc seems lost again and C-x/C-r is needed again to correct the behavior. I am wondering if someone knows what happened here.
Thank you...
I’ve noticed a weird behaviour of (g)Vim: say I have a window with a line longer than its width and I’ve set wrap linebreak cursorline, if I hit s, S, cmotion or cc (but not i, a o or O) on another line and then hit ↵, lines on this window are for some mysterious cause no longer wrapped at word boundaries (it looks as if I’ve set wrap nolinebreak). If I hit Esc and then j or k it returns to normal display.
This should obviously not occur. Is it a bug in Vim or something I did wrong? It occurs when invoking Vim tabula rasa (vim --noplugins -u NONE or gvim --noplugins -u NONE) as well. My machine is Arch Linux, and the Vim version I use is 7.4.537. I’ve tested it on another Arch Linux machine I have and it behaves the same, but when I sshed my DreamHost account, on which Vim 7.3.429 is installed, it behaves as it should.
Note: it doesn’t occur without cursorline on another line, so I guess it’s connected somehow, but I’m not really sure how. It occurs anyway if edit using s or cj on the same long line (than it affects only this line).
Can you confirm or disconfirm this erroneous behaviour occurs on your machine? How can one fix this?
(If it isn’t only me and it is a bug, I’ll send a bug report).
Thank you very much! ☺
As per the discussion in the comments, this was indeed a bug, and was patched in 7.4 with patch #576.
This is a most strange problem, which I only get it using GNU Screen and a Nokia N900. Under vi (both vim and nvi, it turns out) if I type in insert mode one<Enter>two I get
Mtwo
one
So, not only does <Enter> put an M at the beginning of the line, but actually it does something pretty weird in the meantime. Among other things, this issue doesn't let me save and exit.
Any thoughts? Thanks in advance.
POSSIBLE ANSWER: It turns out I wasn't the only one having this issue, which is gone (at least in our case) by simply adding term xterm to your .screenrc. Sorry for not doing a more thorough search before asking...
Your <Enter> is like a carriage return and linefeed (<CRLF>). That's ASCII 10, followed by ASCII 13 (which is the CTRL-M you see). The screen, however, isn't supporting it. Try to do:
export TERM=vt100
then run vi, etc or just
TERM=vt100 vi
which should fix the behavior (assuming you have vt100 terminal capabilities).
Lately I have been encountering a problem in VIM.
I use the shortcut >> (hold shift, press the period key twice) to indent a line. Sometimes I must be hitting something wrong because this shortcut stops working until I restart VIM.
Every time I try to indent with the shortcut it says "1 line >ed 1 time" instead of indenting. Or, if I have 3 lines selected and try to indent them all it will say: "3 lines >ed 1 time".
How do I fix this and restore the shortcut?
Thanks!
I have no idea, why your shortcut is not working, or what's the wrong key that you have pressed.
Regarding your 1 line >ed 1 time message: What you're doing is to shift a number of lines to the right. Vim is just notifying you about what was done, which is: One line is right-shifted one time. The > here is the right shift operator and >ed is just short for "shifted". If you do the opposite it says <ed, which is shifted to the left.
You can find more details in vim's help with: :help >
When a section is marked (visually marked) one > is sufficiant. The 2nd > should start another indentation, but since now nothing is marked it waits for another >.
More than this, I couldn't reproduce any error. (As it was mentioned by frosch03, the msg is just the normal response)
ed was an (well, probably still is) old editor, but I doubt that is what Vim is telling you. I cannot reproduce the message you're getting, nor find anything in the documentation regarding it.
Does this happen also when you're using a clean Vim (when you start it without vimrc with vim/gvim -u none)? If so, could you paste your vimrc if it's not too big somewhere (one of those paste sites should do nicely), so we can take a look to see is there any weird combo inside causing that behaviour.
Apart from that, not much advice I can offer regarding the given data :/