[vim/vim] Why is VIM starting in REPLACE mode? (#6365)
Rain
Describe the bug
A clear and concise description of what the bug is.
(Issues related to the runtime files should be reported to their maintainer, check the file header.)
When you start VIM, you go into REPLACE mode by default
To Reproduce
Detailed steps to reproduce the behavior:
- Run Vim in any directory.
- When VIM is on, enter the default REPLACE mode
Expected behavior
A clear and concise description of what you expected to happen.
Should go into NORMAL mode
Screenshots
If applicable, copy/paste the text or add screenshots to help explain your problem.
Environment (please complete the following information):
-
Vim version [e.g. 8.1.1234] (Or paste the result of
vim --version.)VIM - Vi IMproved 8.2 (2019 Dec 12, compiled Jul 1 2020 09:45:47)
Included patches: 1-1101
Compiled by jiay...@163.com
Huge version without GUI. Features included (+) or not (-):
+acl -farsi +mouse_sgr +tag_binary
+arabic +file_in_path -mouse_sysmouse -tag_old_static
+autocmd +find_in_path +mouse_urxvt -tag_any_white
+autochdir +float +mouse_xterm -tcl
-autoservername +folding +multi_byte +termguicolors
-balloon_eval -footer +multi_lang +terminal
+balloon_eval_term +fork() -mzscheme +terminfo
-browse -gettext -netbeans_intg +termresponse
++builtin_terms -hangul_input +num64 +textobjects
+byte_offset +iconv +packages +textprop
+channel +insert_expand +path_extra +timers
+cindent +ipv6 -perl +title
-clientserver +job +persistent_undo -toolbar
-clipboard +jumplist +popupwin +user_commands
+cmdline_compl +keymap +postscript +vartabs
+cmdline_hist +lambda +printer +vertsplit
+cmdline_info +langmap +profile +virtualedit
+comments +libcall -python +visual
+conceal +linebreak +python3 +visualextra
+cryptv +lispindent +quickfix +viminfo
+cscope +listcmds +reltime +vreplace
+cursorbind +localmap +rightleft +wildignore
+cursorshape -lua -ruby +wildmenu
+dialog_con +menu +scrollbind +windows
+diff +mksession +signs +writebackup
+digraphs +modify_fname +smartindent -X11
-dnd +mouse -sound -xfontset
-ebcdic -mouseshape +spell -xim
+emacs_tags +mouse_dec +startuptime -xpm
+eval -mouse_gpm +statusline -xsmp
+ex_extra -mouse_jsbterm -sun_workshop -xterm_clipboard
+extra_search +mouse_netterm +syntax -xterm_save
system vimrc file: "$VIM/vimrc"
user vimrc file: "$HOME/.vimrc"
2nd user vimrc file: "~/.vim/vimrc"
user exrc file: "$HOME/.exrc"
defaults file: "$VIMRUNTIME/defaults.vim"
fall-back for $VIM: "/usr/local/share/vim"
Compilation: gcc -c -I. -Iproto -DHAVE_CONFIG_H -g -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1
Linking: gcc -L/usr/local/lib -Wl,--as-needed -o vim -lm -ltinfo -ldl -L/usr/lib/python3.8/config-3.8-x86_64-linux-gnu -lpython3.8 -lcrypt -lpthread -ldl -lutil -lm -lm -
OS: Ubuntu 20.04 LTS (wsl)
-
Terminal: Windows Terminal
Additional context
Add any other context about the problem here.
Use the old version VIM version 8.1.2269.
There is no such problem
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.
K.Takata
Doesn't reproduce on Windows 10 2004, Windows Terminal 1.0.1401.0.
Does it occur when you execute with vim --clean?
What is the $TERM setting?
Rain
Execution vim --clean also occurs
What is the
$TERMsetting?
I don't quite understand what that means
K.Takata
Please type echo $TERM on the command line.
Yegappan Lakshmanan
Execution
vim --cleanalso occurs
What is the
$TERMsetting?I don't quite understand what that means
vim-dev ML
On Tue, Jun 30, 2020 at 8:13 PM Rain <vim-dev...@256bit.org> wrote:
> Execution vim --clean also occurs
> [image: avatar]
>
> What is the $TERM setting?
>
> I don't quite understand what that means
>
>
>
This is most probably caused by the terminal you are using not correctly
interpreting
the escape sequences emitted by Vim on startup. Which terminal are you
using and
what is the value of the TERM environment variable?
- Yegappan
Rain
Please type
echo $TERMon the command line.
root@Dev-25:~# echo $TERM
xterm-256color
—
You are receiving this because you commented.
K.Takata
And, what versions of Windows and Windows Terminal do you use?
—
You are receiving this because you commented.
Rain
I'm using terminal Windows Terminal 版本: 1.0.1401.0
The version of Windows I use OS 版本: 10.0.18363 暂缺 Build 18363
—
You are receiving this because you commented.
K.Takata
Hmm, now I can reproduce it when I use WSL1 instead of WSL2.
—
You are receiving this because you commented.
Rain
I'm using WSL1，Is there a solution now, or wait for the next release?
—
You are receiving this because you commented.
Christian Brabandt
@scrawld first of all, I think the xterm-256color is just wrong. I am using :set term=win32 with Windows Terminal 1.0.1401.0. You can also try :set term=builtin_win32 or try any of the other builtin availables one (to see which ones are available, use :set term=foobar
Also can you show the output of :echo v:termresponse please?
—
You are receiving this because you commented.
K.Takata
It seems that $TERM is automatically set to xterm-256color when running Ubuntu on WSL1/2 on Windows Terminal.
I am using
:set term=win32with Windows Terminal 1.0.1401.0.
Isn't that when you running Win32 version of vim.exe? This is the issue when running Linux version of vim.
v:termresponse is empty both on WSL1 and WSL2.
—
You are receiving this because you commented.
Christian Brabandt
Isn't that when you running Win32 version of vim.exe? This is the issue when running Linux version of vim.
Well yes, but the terminal is still win32, isn't it? It shouldn't matter if a linux shell is run inside it or regular powershell/cmd.exe, right?
v:termresponse is empty both on WSL1 and WSL2.
I haven't yet played around with WSL at all yet.
—
You are receiving this because you commented.
K.Takata
Well yes, but the terminal is still win32, isn't it?
No, "Windows Terminal" is a new terminal emulator which is different from the Command Prompt.
—
You are receiving this because you commented.
Christian Brabandt
understood, I am using it myself :) But why would it make a difference between what shell (linux wsl, powershell etc) is run in it?
—
You are receiving this because you commented.
Rain
WSL is a Windows subsystem environment that fully supports the Linux file system
—
You are receiving this because you commented.
K.Takata
This doesn't happen on WSL2, but happens on WSL1. So, the difference is WSL version.
WSL2 uses a real Linux kernel running on a hypervisor.
OTH, WSL1 emulates the Linux kernel. (So, there are some glitches on the WSL1 emulation?)
Windows Terminal itself can also execute PowerShell or Command Prompt in it, and Win32 version of vim.exe can run in it. In this case, Win32 applications are executed via ConPTY, and vim.exe uses term=win32.
So, Win32 applications and Linux applications are executed differently on Windows Terminal.
—
You are receiving this because you commented.
Rain
Now I've set an option set t_u7= to temporarily fix the problem but I'm not sure why this option will fix the problem
—
You are receiving this because you commented.
Christian Brabandt
Most likely, the problem is your terminal is pretending to be xterm while not completely xterm compatible. You might also try :set term=builtin_xterm
—
You are receiving this because you commented.
Rain
set term=builtin_xterm I tried to set this parameter and the problem will still occur
—
You are receiving this because you commented.
Rain
I see an answer that looks like this.
But I don't know what those two parameters mean.
Seems to be an issue with utf-8 ambiguous characters and Windows cmd console. Flag t_u7 is set by default and so vim will request cursor position and get a bad reply from the ssh client.
Workaround: Adding set t_u7= or set ambw=double to your vimrc should fix the problem. set t_u7= will disable requesting cursor position and ambw=double will set the ambiguous characters mode to double.
For more info see vim reference manual: https://vimhelp.org/term.txt.html
—
You are receiving this because you commented.
Bram Moolenaar
> I see an answer that looks like this.
> But I don't know what those two parameters mean.
>
> ```
> Seems to be an issue with utf-8 ambiguous characters and Windows cmd console. Flag t_u7 is set by default and so vim will request cursor position and get a bad reply from the ssh client.
>
> Workaround: Adding set t_u7= or set ambw=double to your vimrc should fix the problem. set t_u7= will disable requesting cursor position and ambw=double will set the ambiguous characters mode to double.
>
> For more info see vim reference manual: https://vimhelp.org/term.txt.html
Right, when the terminal looks like it is xterm compatible, t_u7 is set.
Then when Vim starts up and t_u7 is set, Vim will send a few escape
sequences to the terminal. One is to figure out what happens with
ambiguous width characters. For that it sends one of those characters
and observes the resulting cursor position.
The other sequence, added more recently, checks if requesting the cursor
properties can work. This detects some broken terminal emulaters that
pretend to be xterm compatible, but aren't.
Apparently one of these checks causes the terminal to echo something
back with an "R" in it, which then starts replace mode. Can you find
out what that sequence is? The "script" command only records what is
sent to the terminal, there must be something similar for the other
direction.
The t_u7 response does end in "R", but Vim can recognize it. Perhaps in
your specific situation it doesn't? You could try debugging the
check_termcode() function.
--
ARTHUR: The swallow may fly south with the sun, or the house martin or the
plover seek warmer hot lands in winter, yet these are not strangers to
our land.
SOLDIER: Are you suggesting coconuts migrate?
"Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD
/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
—
You are receiving this because you commented.
Gary Johnson
> Apparently one of these checks causes the terminal to echo something
> back with an "R" in it, which then starts replace mode. Can you find
> out what that sequence is? The "script" command only records what is
> sent to the terminal, there must be something similar for the other
> direction.
characters. Search for "^read(0," to find characters coming
back from the terminal.
HTH,
Gary
vim-dev ML
IWAMOTO Kouichi
Windows Terminal (or windows console) seems to return a broken response to two running CPR (cursor position report) requests.
executed command
$ echo -ne "\e[2J\e[2;2H\e[6n\e[3;3H"; echo -ne "\e[6n"; hd
expected result
^[[2;2R^[[3;3R
00000000 1b 5b 32 3b 32 52 1b 5b 33 3b 33 52 0a |.[2;2R.[3;3R.|
0000000d
actual result
^[^[[3;3R[2;2R
00000000 1b 1b 5b 33 3b 33 52 5b 32 3b 32 52 0a |..[3;3R[2;2R.|
0000000d
termresponse.log when reproduced
0.000001: NV setting crv_status to STATUS_GET
0.094243: NV Sending request for ambiwidth check
0.094668: NV Sending xterm compatibility test sequence.
0.094985: NV Sending CRV request
0.095057: NV Sending FG request
0.095076: NV Sending BG request
0.095179: NV normal character
0.102558: normal character
0.102831: Received compatibility test result: ESC[3;3R[2;2R
0.102851: normal character
0.102871: normal character
0.102885: normal character
0.102909: normal character
0.102934: normal character
0.102953: normal character
1.784192: normal character
2.025001: normal character
2.183770: normal character
—
You are receiving this because you commented.
Bram Moolenaar
IWAMOTO Kouichi wrote:
> Windows Terminal (or windows console) seems to return a broken response to two running CPR (cursor position report) requests.
>
> $ echo -ne "\e[2J\e[2;2H\e[6n\e[3;3H"; echo -ne "\e[6n"; hd
>
> ## expected result
> ^[[2;2R^[[3;3R
> 00000000 1b 5b 32 3b 32 52 1b 5b 33 3b 33 52 0a |.[2;2R.[3;3R.|
> 0000000d
>
> ## actual result
> ^[^[[3;3R[2;2R
> 00000000 1b 1b 5b 33 3b 33 52 5b 32 3b 32 52 0a |..[3;3R[2;2R.|
> 0000000d
>
> ## termresponse.log when reproduced
> 0.000001: NV setting crv_status to STATUS_GET
> 0.094243: NV Sending request for ambiwidth check
> 0.094668: NV Sending xterm compatibility test sequence.
> 0.094985: NV Sending CRV request
> 0.095057: NV Sending FG request
> 0.095076: NV Sending BG request
> 0.095179: NV normal character
> 0.102558: normal character
> 0.102831: Received compatibility test result: ESC[3;3R[2;2R
> 0.102851: normal character
> 0.102871: normal character
> 0.102885: normal character
> 0.102909: normal character
> 0.102934: normal character
> 0.102953: normal character
> 1.784192: normal character
> 2.025001: normal character
> 2.183770: normal character
Thanks for the reproduction example. Clearly this is a problem of the
terminal. Possibly a multi-threading problem. I can't even think of a
workaround (even if I wanted to make one).
Please report this to Microsoft.
--
If all you have is a hammer, everything looks like a nail.
When your hammer is C++, everything begins to look like a thumb.
-- Steve Hoflich, comp.lang.c++
K.Takata
I can reproduce this without Windows Terminal.
Open Command Prompt, execute wsl.exe (WSL1), then execute vim, it starts in the replace mode.
(Maybe I misunderstood the Windows Terminal's architecture. It seems that conhost emulates a VT even on Windows Terminal.)
$ echo -ne "\e[2J\e[2;2H\e[6n\e[3;3H"; echo -ne "\e[6n"; hd
I tried this on WSL2. It returns the correct results most times, but I got the wrong results a few times.
Next, I change the command to $ echo -ne "\e[2J\e[2;2H\e[6n\e[3;3H\e[6n"; hd on WSL1, then the results are always correct.
Conhost's terminal emulator has a timing issue?
phyxmeow
I'm using Manjaro linux in wsl2, and have the same issue.
These code fix the issue but they cause other bugs.
For example in insert mode, arrow keys will insert A, B, C, and D.
" FIX: ssh from wsl starting with REPLACE mode
" https://stackoverflow.com/a/11940894
if $TERM =~ 'xterm-256color'
set noek
endif
By the way, I'm using coc.nvim, if I comment it in vimrc and the issue disappear. I don't quite know why.....
Vim version: 8.2.1537
Windows terminal version: 1.2.2381.0
Bram Moolenaar
I have just sent out Patch 8.2.1595, which makes it possible to see what control codes Vim sends to the terminal.
Start Vim with
vim --cmd "call ch_logfile('logfile', 'w')"
This doesn't log everything, that would include updating the screen and make it hard to read.
Tekki
Debian on WSL2, Windows Terminal 1.2.2381.0:
==== start log session ====
0.023433 : closing channel log in the child process
0.023639 : closing logfile logfile
==== start log session ====
0.141550 : raw terminal output: "�[?1049h�[>4;2m�[?1h�=�[?2004h"
0.142061 : raw terminal output: "�[1;30r�[?12h�[?12l�[22;2t"
0.230408 : raw terminal output: "�[2;1H▽�[6n"
0.230630 : raw terminal output: "�[2;1H �[3;1H�Pzz�\�[0%m�[6n"
0.230867 : raw terminal output: "�[>c"
0.231007 : raw terminal output: "�]10;?��]11;?�"
0.231800 : SafeState: Start triggering
0.233849 : raw key input: "��[3;3R[2;2R�[>0;10;1c"
0.257292 : closing channel log in the child process
0.257753 : closing logfile logfile
0.305449 : closing channel log in the child process
0.305530 : closing logfile logfile
0.362814 : SafeState: reset: key typed
0.363131 : ui_delay(100)
0.464016 : looking for messages on channels
1.374204 : raw key input: "�"
1.374258 : looking for messages on channels
2.245783 : raw key input: ":"
2.248912 : SafeState: Start triggering
2.249053 : looking for messages on channels
2.249069 : SafeState: back to waiting, triggering SafeStateAgain
2.845771 : raw key input: "q"
2.845815 : SafeState: reset: key typed
2.845834 : SafeState: Start triggering
2.846055 : looking for messages on channels
2.846104 : SafeState: back to waiting, triggering SafeStateAgain
3.125866 : raw key input: "
"
3.125934 : SafeState: reset: key typed
3.126201 : Exiting...
3.131164 : raw terminal output: "�[?25l�[?2004l�[>4;m"
3.131595 : raw terminal output: "�[30;1H�[K�[30;1H�[?2004l�[?1l�>"
The unreadable characters are mostly ESC, line 10 is 1B 5D 31 30 3B 3F 07 1B 5D 31 31 3B 3F 07.
Bram Moolenaar
raw key input: "��[3;3R[2;2R�[>0;10;1c"
What happens here is that the escape codes ESC[3;3R and ESC[2;2R are overlapping.
Vim gets two ESC characters first.
That is clearly a problem in the terminal.
Tekki
What happens here is that the escape codes ESC[3;3R and ESC[2;2R are overlapping.
Vim gets two ESC characters first.
That's correct, there are two ESC characters. I'm not sure if this problem is related to the Windows Terminal because the same happens when I go to WSL2 from cmd or powershell.
Dustin L. Howett
Hey, thanks for the excellent investigation. This looks like it will happen on any pair of DSR received by any terminal on windows, provided that they use the console host (conhost.exe) in one way or another. Mintty should of course be unaffected.
We’ll use microsoft/terminal#1637 to track the fix and service it via Terminal (which uses a separate copy of conhost named OpenConsole) and Windows in-box.
Christian Brabandt
looks like a fix has been merged in microsoft/terminal@cb037f3
I suppose a release will happen fairly recently then, so let's close this issue here then.
Christian Brabandt
Closed #6365.
stagira
Hi,
I know this case is closed, but just creating a blank ~/.vimrc file solve the issue for me.
Matthew Israelson
Wiping my .vimrc and replacing with a previous version fixed for me. Not sure why it entered this state. Would be good to know.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.
Matthew Israelson
Bram Moolenaar
> Wiping my .vimrc and replacing with a previous version fixed for me.
> Not sure why it entered this state. Would be good to know.
https://superuser.com/questions/1284561/why-is-vim-starting-in-replace-mode
https://stackoverflow.com/questions/31651762/what-is-wrong-with-this-mapping-vim-starts-in-replace-mode
--
Yesterday is history.
Tomorrow is a mystery.
Today is a gift.
That's why it is called 'present'.
\\\ sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
Sub
Hi,
I know this case is closed, but just creating a blank ~/.vimrc file solve the issue for me.
Worked exactly once, on every subsequent vi(m) launch it goes to replacement mode again.
Using Win10 21H1 19042.1165, Arch Linux on WSL 2 (at least wsl --status reports default version to be 2) Kernel 5.10.16, vim 8.2.3441-1 through cmd, no Windows Terminal installed.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub.
localJetson
Was able to find a workaround in a youtube video: https://www.youtube.com/watch?v=OtPoA_iGbnA
Workaround seems to be working without issue while running kali on wsl1.
Other things I've attempted was one posted here but I was having issues with the arrows key not working on the vim interface.
Workaround : put this into .vimrc
set t_u7=
# alternatively set ambw=double
heyzec
For me, this is happening on vim when only when i use fc to edit the last command on bash/zsh. Surprisingly, this is not a problem when I change the default editor to neovim (export EDITOR=/usr/bin/nvim).
I realised the problematic line in my vimrc is the Esc remapping. If I were to change (for the sake of testing) the Esc remapping to nnoremap <Esc> : then vim starts with :[2;2R showing on the command-line.
If "set t_u7= is added to vimrc, the same mapping instead gives [>65;6003;1c on the command-line. The lack of R character explains why the workaround works.
Using Ubuntu 20.04, and the default gnome-terminal. echo $TERM gives xterm-256color. Hope this helps someone out.
heyzec
For me, this is happening on vim when only when i use fc to edit the last command on bash/zsh. Surprisingly, this is not a problem when I change the default editor to neovim (export EDITOR=/usr/bin/nvim).
I realised the problematic line in my vimrc is the Esc remapping. If I were to change (for the sake of testing) the Esc remapping to nnoremap : then vim starts with :[2;2R showing on the command-line.
If "set t_u7= is added to vimrc, the same mapping instead gives [>65;6003;1c on the command-line. The lack of R character explains why the workaround works.
Using Ubuntu 20.04 (without WSL), and the default gnome-terminal. echo $TERM gives xterm-256color. Hope this helps someone out.
heyzec
For me, this is happening on vim when only when i use fc to edit the last command on bash/zsh. Surprisingly, this is not a problem when I change the default editor to neovim (export EDITOR=/usr/bin/nvim).
I realised the problematic line in my vimrc is the Esc remapping. If I were to change (for the sake of testing) the Esc remapping to nnoremap <Esc> : then vim starts with :[2;2R showing on the command-line.
heyzec
Christian Brabandt
you really really shouldn't map anything to esc, at least not until vim has not completely startup yet. See also https://vi.stackexchange.com/q/2614/71
lacygoill
I realised the problematic line in my vimrc is the Esc remapping.
As already said, don't map anything to <Esc>:
✘
nnoremap <Esc> ...
Alternatively, map whatever you want to a double <Esc>:
✔
nnoremap <Esc><Esc> ...
heyzec
Alternatively, map whatever you want to a double
<Esc>:✔ nnoremap <Esc><Esc> ...
That's a nice workaround that I've never seen before, thanks!
inkpark
" FIX: ssh from wsl starting with REPLACE mode
" https://stackoverflow.com/a/11940894
if $TERM =~ 'xterm-256color'
set noek
endif
that's work for me. https://stackoverflow.com/questions/51388353/vim-changes-into-replace-mode-on-startup
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.
Bram Moolenaar
Note that setting 'esckeys' off has severe side effects. Perhaps you could use a timer to switch it back on after a couple of seconds, or use an autocommand event for that.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.