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...
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 think this issue happens only in text file(s). So very often, but not always, when I open text file with vim, there are new line spaces inside file, even though I don't have anything inside real text file.
If I tried to remove it, or modify anything, everything will screw up, so I need to reopen file. It looks like this:
Couldn't find on the net about this issue.
Check whether this also happens in GVIM. If it only appears in the terminal, you have a wrong value of $TERM, or (less likely) corrupt / wrong termcap definitions. Most terminals should understand a value of
$ export TERM=xterm
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).
Bash uses readline, and readline can delete the word to the right of the cursor with "kill-word".
The problem is in recognizing the keypress of control-delete. When I press them in bash, "5~" is output on the screen. I could just bind for this, but it would mean that one day I need to type "5~", and it deletes a word to the right instead! So I'd much rather discover the correct control sequence.
I have googled, and quite a few resources discuss the "delete" key, but none that I've found discuss "control-delete" key. I've experimented with many variations, but nothing works.
The worst is the hours I've spent on this tedious, mindless grind, when it really should be a non-problem.
EDIT: It's through X, so maybe there's a solution with xev and xmodmap
On my machine, pressing Ctrl-V, Ctrl-Delete outputs this:
^[[3;5~
The ^[ escape character can be replaced with \e, so you can then use bind like this for bash (in your ~/.bashrc for example):
bind '"\e[3;5~":kill-word'
Or, you can add the following to your ~/.inputrc so Ctrl-Delete does kill-word in any program that uses readline:
"\e[3;5~": kill-word
This will bind only the Ctrl-Delete key, you don't have to worry about what will happen if you need to type 5~.
What you see is not the whole truth. It's probably <ESC>5~ or something like that. Try Ctrl-V Ctrl-Delete. The Ctrl-V means "do not interpret the next thing".
So binding <ESC>5~ that should be pretty safe.
Alt+D deletes one word to the right of the cursor
Ctrl+W deletes one word to the left of the cursor
(both are based on Emacs, I believe)
If you type ^Q^V (that's Control-Q followed by Control-V, releasing the Control key between them is fine), and then press Control-Delete, do you get the output you mentioned? I just tried it, and at least using Putty I don't get a response at all. Perhaps the behvior is different on an actual Linux console, though.
For other keys, readline prints a longer sequence, often including a special "command sequence introduction" character, which is hard to type by mistake. Try it, and see if you get a longer sequence with the ^Q^V command (which is, btw, called quoted-insert).
For example, if I press ^Q^V and then Delete (without control held down), readline prints ^[[3~. This tells me I can bind stuff to the Delete key by saying \e[[3~. It seems highely likely that the CSI character is present for you, but you're not seeing it since you're not asking readline to quote the input properly.
Ctrl-W deletes words.
Ctrl-u deletes lines.
They're based on Emacs (M-w and M-u).
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.