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).
Related
i have Vim with plugin vim-go and neocomplete, when o move the cursor from left to right in insert mode this happens
Note: this only happens with go code and vim-go required binaries (such as gocode, godef, goimports, etc..)
someone have same problem?
i am running Ubuntu 14.04.2 LTS 64bits with Kernel 3.13.0-48 Vim 7.4.52 with lua support
thanks in advance
It looks as if you are using gnome-terminal or konsole.
When you use cursor-keys to move around in insert-mode, the keys send escape sequences. In particular, if you happen to press the shift- or control-keys, those can send different escape sequences (with numbers), possibly with semicolons to separate the numbers. There are some limitations on vim's handling strings of that sort, and in some cases (see this discussion) it will get confused and stop interpreting the string, leaving junk on the screen.
The root of the problem is that in vi, the program (mis)uses the escape character for two different reasons:
a special "command" character sent by the user to the editor
the first character in the strings sent by most special keys to an application (including an editor).
The latter requires the program (vim) to wait "a while" to determine which case to use. If you are using a slow machine (or a slow connection) and your keyboard-repeat is fast, that defeats vim's attempt to distinguish the two cases. Likewise, your plugins send many characters to the screen for each keystroke, making vim slower.
It is aggravated by modified keys (using shift- or control-modifiers) since xterm and other terminals encode that information as a number. gnome-terminal and konsole use an older variant of xterm's (see xterm FAQ How can I use shift- or control-modifiers?) which is more easily mistaken by vim as not being an escape sequence.
If it is only a matter of timing, then moving your cursor more slowly would avoid the problem (agreeing that is only a workaround). You can gauge the amount of output done by vim by running it in script to capture the output into a typescript file. I do that to analyze bugs, by sending the data back to the terminal more slowly. Some of those typescript files are surprisingly large, for the little apparent work done.
I changed from neocomplete to YouCompleteMe, the random characters is not showing anymore.
I opened a file in VI and I see a few instances of "^\" What exactly is this character?
Thanks
Seems to be a file-separator ASCII character from the ASCII table.
After poking around on Google, it sounds like it generally sends a quit signal (depending on the machine you're on). See the stty command to determine what it's mapped to on your box. It also has an unexpected and useful effect when using ping, see this blog post.
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.
How do some programs edit whats being displayed on the terminal (to pick a random example, the program 'sl')? I'm thinking of the Linux terminal here, it may happen in other OS's too, I don't know. I've always thought once some text was displayed, it stayed there. How do you change it without redrawing the entire screen?
Depending on the terminal you send control seuqences. Common sequences are for example esc[;H to send the cursor to a specific position (e.g. on Ansi, Xterm, Linux, VT100). However, this will vary with the type or terminal the user has ... curses (in conjunction with the terminfo files) will wrap that information for you.
Many applications make use of the curses library, or some language binding to it.
For rewriting on a single line, such as updating progress information, the special character "carriage return", often specified by the escape sequence "\r", can return the cursor to the start of the current line allowing subsequent output to overwrite what was previously written there.
try this shellscript
#!/bin/bash
i=1
while [ true ]
do
echo -e -n "\r $i"
i=$((i+1))
done
the -n options prevents the newline ... and the \r does the carriage return ... you write again and again into the same line - no scroling or what so ever
If you terminate a line sent to the terminal with a carriage return ('\r') instead of a linefeed ('\n'), it will move the cursor to the beginning of the current line, allowing the program to print more text over top of what it printed before. I use this occasionally for progress messages for long tasks.
If you ever need to do more terminal editing than that, use ncurses or a variant thereof.
There are characters that can be sent to the terminal that move the cursor back. Then text can be overwritten.
There is a list here. Note the "move cursor something" lines.
NCurses is a cross-platform library that lets you draw user interfaces on smart terminals.
Corporal Touchy has answered how this is done at the lowest level. For easier development the curses library gives a higher level of control than simply sending characters to the terminal.
To build on #Corporal Touchy's answer, there are libraries available that will handle some of this functionality for you such as curses/ncurses
I agree with danio, ncurses is the way to go. Here's a good tutorial:
http://tldp.org/HOWTO/NCURSES-Programming-HOWTO/