1

When I open up vim, it starts off with :2R already entered into the command line. I tried commenting out my entire .vimrc, and then it opens up starting in replace mode, with the 2 key pre-pressed (in other words, I insert some text, press <ESC>, and the text appears twice), which is the same as if I had pressed 2R upon opening vim.

How should I go about debugging this? I don't think it can be an issue with my .vimrc, so then what could it be?

For reference, I just updated to version 8.2 via ppa:jonathonf/vim.

nullromo
  • 206
  • 10
  • 2
    Are you using <Esc> in any mappings in your vimrc? In my answer here notice the reference to 2R... Why does terminal vim enter replace mode with my vimrc file? – B Layer Dec 02 '20 at 20:50
  • Thanks for the helpful link. I do use <ESC> in some mappings, but never on the left-hand side. Further, commenting out the whole .vimrc does not stop the 2R from occurring. I opened up vim with a fully-commented .vimrc, and used :scriptnames to find that the only other files loaded are /usr/share/vim/vimrc, ~/.vim/filetype.vim, ~/.vimrc, and some files from /usr/share/vim/vim82/.... – nullromo Dec 02 '20 at 21:59
  • Hmm. That's surprising. What about when you start vim with --clean? If no issues with that then one of those files you listed has to be the culprit (assuming Vim launch is otherwise normal) – B Layer Dec 02 '20 at 22:13
  • 1
    What terminal emulator are you using? What is the $TERM environment variable set to? – filbranden Dec 03 '20 at 03:20
  • This is usually a problem with your terminal emulator and I think happens most often with terminals pretending to be xterm (check $TERM). Make sure to use a recent vim version (not sure if jonathonf/vim is still maintained). Might also try to use :set t_u7= and see if this fixes it. – Christian Brabandt Dec 03 '20 at 10:38
  • The bug persists when running with --clean, but it does not when running with -u NONE. I am using WSL, and echo $TERM gives "xterm-256color." :set t_u7 showed me that it was ^[[6n by default. Adding set t_u7= to my .vimrc seems to fix the problem. Still not fully understanding what t_u7 is, even after reading term.txt, but thanks for the help!! – nullromo Dec 03 '20 at 18:16
  • 1
    If you're using the right kind of terminal (e.g. true xterm) and you send it the special character sequence <Esc>[6n (note: <Esc> prints as ^[) the terminal will reply with the cursor's current row and column. (From xterm terminal you can try it yourself with echo -e "\e[6n".) The exact format of the response is <Esc>r;cR. If cursor is on column 2 then you can see where 2R might come from. I'm not sure of exactly how, though, the mix of Vim and a terminal emulator with mediocre xterm emulation results in the output getting into Vim as a command. – B Layer Dec 04 '20 at 03:21
  • Anyways, by unsetting t_u7 you tell Vim not to use that special sequence anymore even though your TERM envvar indicates you are using some kind of terminal emulator compatible with xterm. – B Layer Dec 04 '20 at 03:28
  • Just noticed you said WSL. I use it, too, (WSL 1 originally and now WSL 2). I don't see this problem. OTOH, I use mintty as my terminal emulator. If you're not doing so then switching to it will likely solve the problem without workarounds. (mintty is an excellent TE, FYI) – B Layer Dec 04 '20 at 03:39
  • @ChristianBrabandt Is there a known bug around t_u7? Based on a bit of digging it seems to me that OPs TE is responding properly to the CSI 6 n request sent in src/term.c:may_req_ambiguous_char_width() but that response is being treated as typed characters. – B Layer Dec 04 '20 at 06:29
  • Or perhaps the TE is sending the correct response but in an incorrect way (e.g. with an unexpected timing or delay), meaning the bug is not Vim's... BTW, I see there was a patch for something that looks very similar but that was all the way back in 8.0.0611 and OP says they're using 8.2. – B Layer Dec 04 '20 at 06:48
  • This is WSL? Good to know, would have been useful to mention at the beginning. It was talking about ppa, so I did not think about this. I believe this is a known problem of the Windows Terminal as mentioned here: https://github.com/vim/vim/issues/6365 Note, this should have been fixed in the latest windows terminal release. – Christian Brabandt Dec 04 '20 at 07:21
  • That must be it. And it is essentially a timing issue. Send two control sequences and the responses come back simultaneously, so to speak, such that their individual characters get intermingled. (!!) Fixed Windows Terminal was released late September. – B Layer Dec 04 '20 at 10:59
  • Thanks again for further explanations/info. I remap ; to :, so it makes sense that some bug would cause #;2R to enter command mode as :2R. Also, with regard to the timing issue, I didn't mention it but ~1-2% of the times I opened vim, the issue wouldn't happen at all. Makes sense with the race condition mentioned. I will look into updating WSL and possibly switching to mintty. Thanks for educating me about some basic concepts here, like the fact that there are escape sequences handled by terminal emulators. In the meantime, would other parts of vim maybe break due to setting t_u7=? – nullromo Dec 04 '20 at 19:05
  • 1
    From what I read and saw in the code that control sequence is used for just a single check at startup (related to character widths in Unicode encodings like utf-8) and thus shouldn't be a source of further problems. – B Layer Dec 05 '20 at 22:50
  • @ChristianBrabandt I thought of adding an answer here since I have lots of data but you cracked the case vis a vis Windows Terminal...thus I think you should have the "right of first refusal"... – B Layer Dec 05 '20 at 23:36
  • @BLayer no problem, please go ahead. – Christian Brabandt Dec 06 '20 at 17:28

1 Answers1

1

To summarize the question comments, this is a terminal emulator control sequence bug. The easiest fix is to install and use WSLTTY. Simply download the latest release and run the installer, then launch WSL from the newly-installed program.

nullromo
  • 206
  • 10