英文:
characters randomly showing up on screen when move the cursor from left to right in vim insert mode
问题
我有安装了插件vim-go和neocomplete的Vim，当我在插入模式下将光标从左向右移动时，会出现这种情况。
**注意：**这只会在使用go代码和vim-go所需的二进制文件（如gocode、godef、goimports等）时发生。
有人遇到过同样的问题吗？
我正在运行Ubuntu 14.04.2 LTS 64位，内核版本为3.13.0-48，Vim版本为7.4.52，支持lua。
提前感谢！
英文:
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
答案1
得分: 3
看起来你正在使用gnome-terminal或konsole。
当你在插入模式下使用光标键移动时，键会发送转义序列。特别是，如果你碰巧按下Shift键或Control键，它们可能会发送不同的转义序列（带有数字），可能用分号分隔数字。Vim对处理这种类型的字符串有一些限制，在某些情况下（参见此讨论），它会混淆并停止解释字符串，导致屏幕上出现垃圾字符。
问题的根源在于，在vi中，程序（误）使用转义字符有两个不同的原因：
- 用户发送给编辑器的特殊“命令”字符
- 大多数特殊键发送给应用程序（包括编辑器）的字符串中的第一个字符。
后者要求程序（vim）等待“一段时间”来确定使用哪种情况。如果你使用的是一台速度较慢的计算机（或者连接速度较慢），并且键盘重复速度很快，那么这将破坏vim区分这两种情况的尝试。同样，你的插件对于每个按键都会向屏幕发送许多字符，使得vim变慢。
这一问题在使用修改过的键（使用Shift键或Control键修饰符）时更加严重，因为xterm和其他终端将该信息编码为一个数字。gnome-terminal和konsole使用了xterm的一个较旧的变体（参见xterm FAQ 如何使用Shift键或Control键修饰符？），这更容易被vim误认为不是转义序列。
如果只是一个时间问题，那么以较慢的速度移动光标可以避免这个问题（同意这只是一个权宜之计）。你可以通过在script中运行vim将输出捕获到一个typescript文件中来评估vim所做的输出量。我通过将数据以较慢的速度发送回终端来分析错误。其中一些typescript文件的大小令人惊讶，与表面上的工作量相比。
英文:
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.
答案2
得分: 0
我从neocomplete更换到了YouCompleteMe，现在不再显示随机字符了。
英文:
I changed from neocomplete to YouCompleteMe, the random characters is not showing anymore.
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库，让每个人都能够通过互相帮助和分享经验来进步。
评论