Neovim: After pressing Escape and then a letter, it will output strange characters (eg <Esc>+j =ê)

[edi9999]

I'm using one of the latest version of nvim:

NVIM 0.0.0-alpha (compiled Feb 17 2015 16:50:51)
Commit: ?
Build type: RelWithDebInfo
Compilation: /usr/bin/x86_64-linux-gnu-gcc -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -Wconversion -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1 -Og -g -Wall -Wextra -pedantic -Wno-unused-parameter -Wstrict-prototypes -std=gnu99 -DINCLUDE_GENERATED_DECLARATIONS -DHAVE_CONFIG_H -I/build/buildd/neovim-0.0.0+git201502170610+2~ubuntu14.10.1/build/config -I/build/buildd/neovim-0.0.0+git201502170610+2~ubuntu14.10.1/src -I/build/buildd/neovim-0.0.0+git201502170610+2~ubuntu14.10.1/.deps/usr/include -I/build/buildd/neovim-0.0.0+git201502170610+2~ubuntu14.10.1/.deps/usr/include -I/usr/include/luajit-2.0 -I/build/buildd/neovim-0.0.0+git201502170610+2~ubuntu14.10.1/.deps/usr/include -I/usr/include -I/build/buildd/neovim-0.0.0+git201502170610+2~ubuntu14.10.1/build/src/nvim/auto -I/build/buildd/neovim-0.0.0+git201502170610+2~ubuntu14.10.1/build/include
Compiled by buildd@lgw01-13  Features included (+) or not (-):
+acl             +farsi           -mouse_gpm       +tag_old_static
+arabic          +file_in_path    +mouse_netterm   -tag_any_white
+autocmd         +find_in_path    +mouse_sgr       +termresponse
-browse          +folding         -mouse_sysmouse  +textobjects
+byte_offset     -footer          +mouse_urxvt     +title
+cindent         +fork()          +mouse_xterm     -toolbar
-clipboard       +gettext         +multi_byte      +user_commands
+cmdline_compl   +iconv           +multi_lang      +vertsplit
+cmdline_hist    +insert_expand   +path_extra      +virtualedit
+cmdline_info    +jumplist        +persistent_undo +visual
+comments        +keymap          +postscript      +visualextra
+conceal         +langmap         +printer         +viminfo
+cscope          +libcall         +profile         +vreplace
+cursorbind      +linebreak       +quickfix        +wildignore
+cursorshape     +lispindent      +reltime         +wildmenu
+dialog_con      +listcmds        +rightleft       +windows
+digraphs        +localmap        +scrollbind      +writebackup
-dnd             +menu            +signs           -X11
-ebcdic          +mksession       +smartindent     -xfontset
-emacs_tags      +modify_fname    +startuptime     -xsmp
+eval            +mouse           +statusline      -xterm_clipboard
+ex_extra        -mouseshape      +syntax
+extra_search    +mouse_dec       +tag_binary
   system vimrc file: "$VIM/nvimrc"
     user vimrc file: "$HOME/.nvimrc"
 2nd user vimrc file: "~/.nvim/nvimrc"
      user exrc file: "$HOME/.exrc"
  fall-back for $VIM: "/usr/share/nvim"

If I press <Esc> then j in insert mode, the character ê appears.
Same for all other keys.

However when I use jj (which I remapped), I don't get this behaviour. I don't get the behaviour on the console (inside tmux), and I don't get it with standard vim with the same configuration.

I have just rolledback to : NVIM 0.0.0-alpha (compiled Feb 16 2015 18:09:24) and this solves the problem (so the bug is really new)

Any Ideas ?

[tarruda]

In what terminal emulator do you get this? Also, can you link to your vimrc?

[geoffharcourt]

I had this problem in iTerm2 (xterm emulation) on OSX using this vimrc. It was happening intermittently, but I haven't been able to reproduce it since 366662d932551e558d10f09887ddf144ed5db34b was committed this morning.

[tarruda]

I had this problem in iTerm2 (xterm emulation) on OSX using this vimrc. It was happening intermittently, but I haven't been able to reproduce it since 366662d was committed this morning.

Great. @edi9999 do you still have the problem after @366662d?

[geoffharcourt]

@tarruda, it looks like the issue here is similar to a side issue discussed in #2016 (which looks like it is tackling a few semi-related issues).

[bugeats]

+1 getting this in iTerm 2 + tmux.

Here's my .nvimrc

I just updated my build via homebrew:

NVIM 0.0.0-alpha+201502181331 (compiled Feb 18 2015 11:30:17)
Commit: 366662d932551e558d10f09887ddf144ed5db34b

I also noticed that keyboard events are much more laggy. It feels like a timing issue.

---

EDIT

Just reverted to:

NVIM 0.0.0-alpha+201502172309 (compiled Feb 18 2015 12:05:04)
Commit: 26371f4cccaf5f273f2e7ed4733b95a01ca83ddb

... and laggyness is gone, but strange character insert is still happening. Going to revert further back now. BRB. :)

---

EDIT 2

Went all the way back to:

NVIM 0.0.0-alpha+201502151219 (compiled Feb 18 2015 12:16:43)
Commit: fd636fc6dcd8a547daab1544432877bf8efa0c1e

... and the strange character insert is gone!

I wasn't very clever about picking reversions. Didn't bisect or anything. This one works though.

[edi9999]

I'm running Konsole for my terminal emulator, on xubuntu.

The 0.0.0+git201502181631+2~ubuntu14.10.1 build has this issue solved

EDIT: After some testing, the issue is still there , I probably had an old neovim session running.

Here are my Plugins:

Bundle 'ctrlpvim/ctrlp.vim'
Bundle 'vim-scripts/Align'
Bundle 'vim-scripts/Decho'
Bundle 'vim-scripts/dbext.vim'
Bundle "mattn/emmet-vim"
Bundle 'tommcdo/vim-exchange'
Bundle 'floobits/floobits-neovim'
Bundle 'ryanss/vim-hackernews'

[tarruda]

After a couple of hours fighting to install OSX and its development tools on my VM, I've managed to reproduce the hang and came up with a patch. It seems to fix for me but I'd like some confirmation from others in this thread:

 diff --git a/src/nvim/tui/term_input.inl b/src/nvim/tui/term_input.inl
index dba970e..62e92d6 100644
--- a/src/nvim/tui/term_input.inl
+++ b/src/nvim/tui/term_input.inl
@@ -11,7 +11,7 @@
 struct term_input {
   int in_fd;
   TermKey *tk;
-  uv_tty_t input_handle;
+  uv_pipe_t input_handle;
   uv_timer_t timer_handle;
   RBuffer *read_buffer;
   RStream *read_stream;
@@ -259,8 +259,8 @@ static TermInput *term_input_new(void)
   int curflags = termkey_get_canonflags(rv->tk);
   termkey_set_canonflags(rv->tk, curflags | TERMKEY_CANON_DELBS);
   // setup input handle
-  uv_tty_init(uv_default_loop(), &rv->input_handle, rv->in_fd, 1);
-  uv_tty_set_mode(&rv->input_handle, UV_TTY_MODE_RAW);
+  uv_pipe_init(uv_default_loop(), &rv->input_handle, 0);
+  uv_pipe_open(&rv->input_handle, 0);
   rv->input_handle.data = NULL;
   rv->read_buffer = rbuffer_new(0xfff);
   rv->read_stream = rstream_new(read_cb, rv->read_buffer, rv);
@@ -279,7 +279,6 @@ static TermInput *term_input_new(void)

 static void term_input_destroy(TermInput *input)
 {
-  uv_tty_reset_mode();
   uv_timer_stop(&input->timer_handle);
   rstream_stop(input->read_stream);
   rstream_free(input->read_stream);
diff --git a/src/nvim/tui/tui.c b/src/nvim/tui/tui.c
index 57119b9..ad2005f 100644
--- a/src/nvim/tui/tui.c
+++ b/src/nvim/tui/tui.c
@@ -113,6 +113,7 @@ void tui_start(void)
   data->write_loop = xmalloc(sizeof(uv_loop_t));
   uv_loop_init(data->write_loop);
   uv_tty_init(data->write_loop, &data->output_handle, data->out_fd, 0);
+  uv_tty_set_mode(&data->output_handle, UV_TTY_MODE_RAW);

   // Obtain screen dimensions
   update_size(ui);
@@ -169,6 +170,7 @@ static void tui_stop(UI *ui)
   // Disable bracketed paste
   unibi_out(ui, (int)data->unibi_ext.disable_bracketed_paste);
   flush_buf(ui);
+  uv_tty_reset_mode();
   uv_close((uv_handle_t *)&data->output_handle, NULL);
   uv_run(data->write_loop, UV_RUN_DEFAULT);
   if (uv_loop_close(data->write_loop)) {

[geoffharcourt]

Is this in a branch? I looked in tui-fixes-2 and couldn't find it. I'm happy to build locally and test on my machine.

[tarruda]

Is this in a branch? I looked in tui-fixes-2 and couldn't find it. I'm happy to build locally and test on my machine.

Its a patch, if it resolves the issue I will put into #2025. You can save it to a file and apply with patch -p1 < file.patch

[bugeats]

I'm a dummy and need a branch so I build with homebrew.

[tarruda]

very well, I applied the patch to #2025

[geoffharcourt]

After building locally I think the patch resolves the issue. I opened around a bunch of flies and edited buffers and didn't have any recurrence of the issue. I've only had 15 mins or so to play around with it, but I was having issues every couple of minutes before, so I think this worked. Thanks very much for the hard work!

[bugeats]

I built from head "https://github.com/tarruda/neovim.git", :branch => "tui-fixes-2" via homebrew.

NVIM 0.0.0-alpha+201502191759 (compiled Feb 19 2015 13:23:47)
Commit: abc54a314ade4fa9d145e07b29d2bf5c18b75a2b

At first I thought the problem was solved. It was less laggy, and my initial inserts did ok. After a few inserts though, the problem appeared. This time it seemed worse. It was like my ESC key was sticky or something.

---

EDIT

My homebrew formula I've been modifying. Is libtermkey dep a problem?

class Neovim < Formula
  homepage "http://neovim.org"
  # Working now
  head "https://github.com/neovim/neovim.git", :revision => "fd636fc6dcd8a547daab1544432877bf8efa0c1e"
  # tarruda's attempted fix
  # head "https://github.com/tarruda/neovim.git", :branch => "tui-fixes-2"

  depends_on "cmake" => :build
  depends_on "libtool" => :build
  depends_on "automake" => :build
  depends_on "autoconf" => :build
  depends_on "pkg-config" => :build
  depends_on "gettext" => :build
  depends_on :python => :recommended if MacOS.version <= :snow_leopard

  resource "libuv" do
    url "https://github.com/libuv/libuv/archive/v1.2.0.tar.gz"
    sha1 "38d1ba349fcfc1b221140523ba3d7cf3ea38c20b"
  end

  resource "msgpack" do
    url "https://github.com/msgpack/msgpack-c/archive/b4eba4ba090e8cd6d8332410e252296a62b7e56d.tar.gz"
    sha1 "768e60e3936cd0d0e4f1d58ca86a78eeb895931b"
  end

  resource "luajit" do
    url "http://luajit.org/download/LuaJIT-2.0.3.tar.gz"
    sha1 "2db39e7d1264918c2266b0436c313fbd12da4ceb"
  end

  resource "luarocks" do
    url "https://github.com/keplerproject/luarocks/archive/0587afbb5fe8ceb2f2eea16f486bd6183bf02f29.tar.gz"
    sha1 "61a894fd5d61987bf7e7f9c3e0c5de16ba4b68c4"
  end

  resource "libunibilium" do
    url "https://github.com/mauke/unibilium/archive/520abbc8b26910e2580619f669b5cc2c4ef7f864.tar.gz"
    sha1 "c546e5e8861380f5c109a256f25c93419e4076bf"
  end

  resource "libtermkey" do
    url "https://github.com/neovim/libtermkey/archive/8c0cb7108cc63218ea19aa898968eede19e19603.tar.gz"
    sha1 "54e8b6914dab10d4467d2a563f80053a99849fcb"
  end

  def install
    ENV.deparallelize

    resources.each do |r|
      r.stage(buildpath/".deps/build/src/#{r.name}")
    end

    system "make", "CMAKE_BUILD_TYPE=RelWithDebInfo", "CMAKE_EXTRA_FLAGS=\"-DCMAKE_INSTALL_PREFIX:PATH=#{prefix}\"", "install"
  end

  def caveats; <<-EOS.undent
      If you want support for Python plugins such as YouCompleteMe, you need
      to install a Python module in addition to Neovim itself.

      See :h nvim-python-quickstart for more information.
    EOS
  end

  test do
    (testpath/"test.txt").write("Hello World from Vim!!")
    system bin/"nvim", "-u", "NONE", "+s/Vim/Neovim/g", "+wq", "test.txt"
    assert_equal "Hello World from Neovim!!", File.read("test.txt").strip
  end
end

[geoffharcourt]

@bugeats, do you get that problem outside of tmux?

I had really sluggish escapes in tmux until I did set -s escape-time 0 in tmux.conf.

[bugeats]

Ok, looking for the issue running abc54a314ade4fa9d145e07b29d2bf5c18b75a2b

iTerm 2 without tmux: OK
iTerm 2 with tmux: NOPE
iTerm 2 with tmux and set -s escape-time 0 in tmux.conf: OK

So there you go.

@geoffharcourt escape-time 0 makes it feel quicker. I think I'll keep it. :) thanks.

[khalidchawtany]

I am using the same build as @bugeats and the problem still exists inside and outside of tmux using terminal or iTerm.

NVIM 0.0.0-alpha+201502191759 (compiled Feb 20 2015 00:48:35)
Commit: abc54a314ade4fa9d145e07b29d2bf5c18b75a2b

[kopischke]

As noted in #2016, I can confirm the issue persists in the _tui-fixes-2_ branch, running OS X 10.10.2 in Terminal.app, no multiplexer. Neovim version:

NVIM 0.0.0-alpha+201502192025 (compiled Feb 20 2015 11:02:37)                                                           
Commit: da364c4f156bb47f2f263af68e30d86528c75252

still exhibits delayed ESC response / spurious characters inserts in insert mode. Setting ttimeoutlen=-1 alleviates the issue somewhat, but not entirely.

[tarruda]

The problem here is that libtermkey is parsing <esc>+j(@edi9999 example) as alt+j which is how most terminals encode the alt modifier. With the old interface you had to do something like set <m-a>=^[a to get alt+a working.

With the new TUI, ttimeoutlen is being used as a timeout before the esc byte(\x1b) is forwarded as the <esc> key to nvim, so if you have ttimeoutlen=500 and press esc followed by j in less than 500 milliseconds, it will be forwarded as alt+j.

Note that tmux also has a similar setting, which is escape-time as explained by @geoffharcourt. escape-time has a default value of 500 milliseconds, which can also result in alt+j being sent to nvim.

Setting nvim ttimeoutlen to -1 and tmux escape-time to 0(or a very low value) should fix the problem.

@khalidchawtany / @kopischke if you still experience the problem after setting both ttimeoutlen to -1 and escape-time to a low value like 5, then it must be another issue.

[kopischke]

if you still experience the problem after setting both ttimeoutlen to -1 and escape-time to a low value like 5, then it must be another issue.

I’m in plain Terminal.app, no _tmux_, so ttimeoutlen is the only setting I can tweak, and I can confirm pressing ESC still exhibits both the spurious character insertion and the timeout issues at ttimoutlen=-1.

EDIT: Apparently, ESC sends alt+a, which results in å being displayed (OS X maps alt+<key> to special characters by default).

[tarruda]

@kopischke do you have a simple vimrc I can use for reproducing the problem?

[kopischke]

@tarruda good call, I should have tested that earlier – turns out it doesn’t happen with $VIMINITunset and nvim -u NONE, so it seems to be an issue with my setup. The matchem plug-in maps

i  <Esc>       * <C-R>=<SNR>78_RepeatFixupFlush("<c-[>")<CR><Esc>

– would that explain the behaviour I’m seeing?

[tarruda]

– would that explain the behaviour I’m seeing?

Hmm, I think this could be the cause. What happens when you comment those lines?

[kopischke]

What happens when you comment those lines?

nope, not it – I removed _matchem_ altogether and the problematic behaviour persists without any insert mode <Esc> mappings. Looks like I’m gonna have to go through my .vimrc line by line and plug-in by plug-in. Will report back when I have a result.

[tarruda]

nope, not it – I removed matchem altogether and the problematic behaviour persists without any insert mode mappings. Looks like I’m gonna have to go through my .vimrc line by line and plug-in by plug-in. Will report back when I have a result.

Does this problem happen with other terminals?

[kopischke]

Does this problem happen with other terminals?

Yup, happens in iTerm 2 2.0 too. Working on isolating this ATM: I’m down to checking my .vimrc already, as excluding all my plug-ins in one fell swoop still left me with the problematic behaviour.

[kopischke]

I’m giving up on reliably reproducing this: now ttimeoutlen=-1 is set in my .nvimrc (as opposed to being set later from the command line), I’m not having any issues even with all plug-ins activated.

@tarruda ignore my reports for the time being; I will come back to them if the issue resurfaces.

[kopischke]

With the new TUI, ttimeoutlen is being used as a timeout before the esc byte(\x1b) is forwarded as the key to nvim, so if you have ttimeoutlen=500 and press esc followed by j in less than 500 milliseconds, it will be forwarded as alt+j.

Considering ttimeoutlen also has other uses, would it make sense to add separate handling for ESC timeout (e.g. esctimeoutlen or such)?

[tarruda]

Considering ttimeoutlen also has other uses, would it make sense to add separate handling for ESC timeout (e.g. esctimeoutlen or such)?

What do you think of this commit: https://github.com/tarruda/neovim/commit/8dc9ee2cc3c87807034252128bdeef01b5830ed2 ?

Since the new TUI uses a different mechanism for parsing keys(alt is recognized by default), I thought it was better to only use ttimeout for determining when esc should be timed out. Since ttimeout is set to false by default, I think this will result a more compatible behavior.

[kopischke]

What do you think of this commit: tarruda@8dc9ee2 ?

:+1: those new timeout / ttimeout semantics make far sense to me than Vim’s rather convoluted original ones (I mean, the table explaining their interaction alone yells “cruft”).

[khalidchawtany]

Thanks @tarruda this new commit solves the issue.

With these lines in my vimrc NeoVim works as expected.

  set timeout
  set timeoutlen=750
  set ttimeoutlen=250

  "NeoVim handles ESC keys as alt+key, set this to solve the problem
  if has('nvim')
     set ttimeout
     set ttimeoutlen=0
  endif

NVIM 0.0.0-alpha+201502200943 (compiled Feb 20 2015 15:53:21)
Commit: 9894720a0557cb80e11d33cb3b3a8fbf23827b9c

[khalidchawtany]

@tarruda pressing the HOME key does not move the cursor to the beginning of a line in insert mode. Nor the END key takes the cursor to the end.

Edit:

Another thing is that I had these lines in my vimrc to change the shape of the cursor in insert mode to a vertical bar and a box in normal mode. However, know it does not work.

  if exists('$TMUX')
    let &t_SI = "\<Esc>Ptmux;\<Esc>\<Esc>]50;CursorShape=1\x7\<Esc>\\"
    let &t_EI = "\<Esc>Ptmux;\<Esc>\<Esc>]50;CursorShape=0\x7\<Esc>\\"
  else
    let &t_SI = "\<Esc>]50;CursorShape=1\x7"
    let &t_EI = "\<Esc>]50;CursorShape=0\x7"
  endif

[tarruda]

@tarruda pressing the HOME key does not move the cursor to the beginning of a line in insert mode. Nor the END key takes the cursor to the end.

Any chance you are using tmux with a different TERM variable value? Check this out:http://stackoverflow.com/questions/18600188/home-end-keys-do-not-work-in-tmux

[khalidchawtany]

But it works in Vim. Is it still related?

>> echo $TERM
screen-256color

[tarruda]

But it works in Vim. Is it still related?

Its not related to this issue. Whats the output of infocmp $TERM?

[khalidchawtany]

infocmp $TERM

#       Reconstructed via infocmp from file: /usr/share/terminfo/73/screen-256color
screen-256color|GNU Screen with 256 colors,
        am, km, mir, msgr, xenl,
        colors#256, cols#80, it#8, lines#24, ncv#3, pairs#32767,
        acsc=++\,\,--..00``aaffgghhiijjkkllmmnnooppqqrrssttuuvvwwxxyyzz{{||}}~~,
        bel=^G, blink=\E[5m, bold=\E[1m, cbt=\E[Z, civis=\E[?25l,
        clear=\E[H\E[J, cnorm=\E[34h\E[?25h, cr=^M,
        csr=\E[%i%p1%d;%p2%dr, cub=\E[%p1%dD, cub1=^H,
        cud=\E[%p1%dB, cud1=^J, cuf=\E[%p1%dC, cuf1=\E[C,
        cup=\E[%i%p1%d;%p2%dH, cuu=\E[%p1%dA, cuu1=\EM,
        cvvis=\E[34l, dch=\E[%p1%dP, dch1=\E[P, dl=\E[%p1%dM,
        dl1=\E[M, ed=\E[J, el=\E[K, el1=\E[1K, enacs=\E(B\E)0,
        flash=\Eg, home=\E[H, ht=^I, hts=\EH, ich=\E[%p1%d@,
        il=\E[%p1%dL, il1=\E[L, ind=^J, initc@, is2=\E)0, kbs=^H,
        kcbt=\E[Z, kcub1=\EOD, kcud1=\EOB, kcuf1=\EOC, kcuu1=\EOA,
        kdch1=\E[3~, kend=\E[4~, kf1=\EOP, kf10=\E[21~,
        kf11=\E[23~, kf12=\E[24~, kf2=\EOQ, kf3=\EOR, kf4=\EOS,
        kf5=\E[15~, kf6=\E[17~, kf7=\E[18~, kf8=\E[19~, kf9=\E[20~,
        khome=\E[1~, kich1=\E[2~, kmous=\E[M, knp=\E[6~, kpp=\E[5~,
        nel=\EE, op=\E[39;49m, rc=\E8, rev=\E[7m, ri=\EM, rmacs=^O,
        rmcup=\E[?1049l, rmir=\E[4l, rmkx=\E[?1l\E>, rmso=\E[23m,
        rmul=\E[24m, rs2=\Ec\E[?1000l\E[?25h, sc=\E7,
        setab=\E[%?%p1%{8}%<%t4%p1%d%e%p1%{16}%<%t10%p1%{8}%-%d%e48;5;%p1%d%;m,
        setaf=\E[%?%p1%{8}%<%t3%p1%d%e%p1%{16}%<%t9%p1%{8}%-%d%e38;5;%p1%d%;m,
        sgr=\E[0%?%p6%t;1%;%?%p1%t;3%;%?%p2%t;4%;%?%p3%t;7%;%?%p4%t;5%;m%?%p9%t\016%e\017%;,
        sgr0=\E[m\017, smacs=^N, smcup=\E[?1049h, smir=\E[4h,
        smkx=\E[?1h\E=, smso=\E[3m, smul=\E[4m, tbc=\E[3g,

[tarruda]

@khalidchawtany since you are using screen-256color it should work. please open a new issue for this

[Tranquility]

Another thing is that I had these lines in my vimrc to change the shape of the cursor in insert mode to a vertical bar and a box in normal mode. However, know it does not work.

@khalidchawtany you now need to set the env variable NVIM_TUI_ENABLE_CURSOR_SHAPE=1 and neovim should just do the right thing.

https://github.com/neovim/neovim/pull/2007#issuecomment-74863439

[tarruda]

@khalidchawtany you now need to set the env variable NVIM_TUI_ENABLE_CURSOR_SHAPE=1 and neovim should just do the right thing.

Sorry if thats cumbersome, later I will add a better way to configure the UI layer

[khalidchawtany]

@Tranquility & @tarruda that did the trick. Thanks.

[edi9999]

set -s escape-time 0 in .tmux.conf worked for me

[Xe]

I get this on urxvt with tmux.

[jordansissel]

Confirmed @edi9999's tmux config change solved my problem.

[nhoad]

For a very similar fix but for screen, setting maptimeout 5 in ~/.screenrc has fixed Neovim within screen.

[mjessome]

I have this problem with neovim + tmux, but not with vim + tmux. If this is really an issue with tmux configuration, why does this not happen when editing in vim?

[justinmk]

https://github.com/neovim/neovim/wiki/Troubleshooting#pressing-esc-when-running-nvim-in-tmux-or-gnu-screen-inserts-characters

why does this not happen when editing in vim?

A different problem happens in Vim. If you do not lower your tmux escape time, escaping out of insert mode will take a long time. So most users end up lowering it anyways.

[mjessome]

@justinmk Thanks for the response. I agree that with tmux + vim, just pressing Esc takes a while to exit insert mode; however, if I press Esc + 'j' quickly, insert mode is immediately escaped and my cursor goes down a line, as opposed to nvim's behaviour of entering a special character.

I do understand that this may be a tmux configuration issue and will adjust my configs accordingly, though I don't quite comprehend the difference in behaviour here.

[justinmk]

We are setting the high bit for some reason. @leonerd said libtermkey is not doing it so maybe @tarruda can comment.

[chevtek]

I had the same question since vim seemed to work fine in tmux but neovim does not. Regardless, setting the escape time option in tmux has solved my issue so I'm happy :)

[evilguc]

:+1: on @chevex's and some others' responses. Issue with or

Following @justinmk's answer works well:

https://github.com/neovim/neovim/wiki/Troubleshooting#pressing-esc-when-running-nvim-in-tmux-or-gnu-screen-inserts-characters

why does this not happen when editing in vim?
A different problem happens in Vim. If you do not lower your tmux escape time, escaping out of insert mode will take a long time. So most users end up lowering it anyways.

[dsimmons]

Having just encountered this, wanted to shed some additional light.

1. This happens to me _reproducibly_ in nvim (0.1.0) and _not_ vim, _outside_ of tmux and _regardless_ of whether I'm using iTerm2 or Terminal.app.
2. My ttimeout and ttimeoutlen config settings are as follows:

VimL set ttimeout set ttimeoutlen=100

These are the same settings that can be found in vim-sensible (see related issue #105).

I have no desire to alter these values because, as mentioned above, exiting INSERT mode with <ESC> and performing a subsequent action (eg. SHIFT+O) has a noticeable ~1s lag otherwise.

In theory, setting :help noesckeys should circumvent the problem for <ESC> specifically (as opposed to other :help keycodes), but even that doesn't work based on my testing.

For now, this is a bit of a dealbreaker, as it has happened to me (consistently) no less than once per minute for the past ~30 minutes. In the interim, I'll be reverting back to Vim to GSD :smile:

Steps to reproduce: Fire open nvim. Enter INSERT mode. In quick succession, hit <ESC>j and observe the special character ê that's output.

[leonerd]

I expect this is a consequence of vim's input queue system that conflates the ideas of Alt characters and Unicode codepoints, combined with neovim's use of libtermkey that more readily notices Alt prefixing in the first place.

In regular vim (which neovim builds on), there is no distinction between the concept of <Alt-j> and the Unicode character ê; they are both represented by the number 0xEA. The former because j is 0x7A inclusive ORed with 0x80, the latter because it is Unicode codepoint U+00EA. However, in regular vim, vim doesn't automatically believe that an inbound ESC byte followed immediately by a letter is an Alt-prefixed letter; it must be taught this individually. Neovim though, uses libtermkey for its keyboard management, so it recognises that automatically, which then upsets the latter.

I offer this as a general analysis of the problem; but I don't really have any strong suggestions on how to fix it. Ideally it would be nice to fix vim's forced conflation of the two separate concepts; but that cuts right to the very core of how vim's (and hence neovim's) input queue mechanism works. I don't know if neovim is prepared to make such a bold change as to alter that.

[leonerd]

I've had a quick hunt around in the source code to see if I could find what to fix, but I'm afraid I got lost somewhere around the maze of twisty passages that is input_enqueue() + getchar(). Maybe someone with more familiarity with the core code could point me at where this Alt- prefixing gets pulled apart and I can see if I can suggest a fix.

[dsimmons]

Thanks for the insight @leonerd!

_I offer this as a general analysis of the problem; but I don't really have any strong suggestions on how to fix it. Ideally it would be nice to fix vim's forced conflation of the two separate concepts; but that cuts right to the very core of how vim's (and hence neovim's) input queue mechanism works. I don't know if neovim is prepared to make such a bold change as to alter that._

Fully agree here, this is a tricky one (assuming there's no ideal scenario). Crossing my fingers that someone with more intimate knowledge can think of good compromise.

@edi9999 @tarruda: Is it possible to re-open this? As mentioned above, it's completely separate from anything tmux-related, is still very much present, and would benefit from increased visibility amongst project maintainers as an outstanding issue.

[justinmk]

set ttimeout
set ttimeoutlen=100

I have no desire to alter these values because

@dsimmons If you won't change the settings as required then there is not much we can do.

exiting INSERT mode with <ESC> and performing a subsequent action (eg. SHIFT+O) has a noticeable ~1s lag otherwise.

Cannot reproduce this.

[dsimmons]

@justinmk: You're correct -- I just verified the above in nvim. However, I also verified that the scenario outline above _does_ happen in vanilla Vim without ttimeout and ttimeoutlen set.

More importantly, what this effectively highlights is a key difference (pun intended :wink:) between Vim and NeoVim, as was previously mentioned by @leonerd. Accordingly, as a user, I have to know to reset those configuration options when moving between Vim and NeoVim to achieve parity.

Put another way, given the exact same two configuration files for Vim and NeoVim, I don't observe the same behavior respectively. At the very least, if backwards compatibility isn't desired to be maintained in this scenario, it should ideally be called out such that someone in our shoes a few months or years from now knows that this is a "gotcha", especially in the interest of a clear "upgrade path" for the many users like myself trying to make the transition.

EDIT: In re-reading this, an interesting thought occurred to me -- for the NeoVim project, it might be worth having a binary that "lints" existing .vimrc's and throws warnings for options that have different observed behaviors in NeoVim, somewhat similar to brew doctor. That way, a new user can run it on-demand (because it's not something you'd run _too_ frequently) and uncover issues like this upfront.

Just a random (but orthogonal) idea :smile:

[justinmk]

@dsimmons I agree that this is a jarring difference between Vim and Neovim. I have suggested that we do not allow these settings to be configurable at all. Perhaps you can create a new issue regarding this and see what objections there are.

[dsimmons]

@justinmk happy to!

Just so that I'm clear, would this issue be to highlight the aforementioned difference or to propose a new utility that sanity-checks existing .vimrc's for compatibility issues (or both)?

[justinmk]

Only to propose that we enforce ideal settings for ttimeout and/or ttimeoutlen, somehow.

[edi9999]

@dsimmons

exiting INSERT mode with and performing a subsequent action (eg. SHIFT+O) has a noticeable ~1s lag otherwise.

Cannot reproduce this either using nvim -u NONE outside of tmux. Maybe you have some mappings or something in your .vimrc that has this effect ?

[dsimmons]

@edi9999 see this comment.

[rf]

Happens for me on OSX in both screen and tmux with nvim -u NONE. Doesn't happen outside of screen / tmux. Let me know if I can give any information to help debug. I'd really love to switch to neovim but I can't until this is fixed.

[dsimmons]

@rf: With all due respect, that's a tmux issue rather than a NeoVim issue. Although I don't have this problem myself when using tmux, @edi9999 posted a configuration option above people have said works.

Separately, completely independent of a terminal multiplexer or lack thereof, this issue exists as a difference between core Vim and NeoVim due to the way ttimeout works.

Again, I don't mean this negatively, but it'd help if we stopped conflating the two issues! :smile:

[ode79]

The fix @edi9999 posted above for the tmux conf file worked for me. Thanks

[justinmk]

@rf @dsimmons The issues mentioned here should be greatly improved on latest master.

[dsimmons]

@justinmk I'll try it out when I get a chance and report back!

EDIT: Works like a charm on HEAD! Thanks so much for addressing this @justinmk! :smile:

EDIT 2: I just wanted to also be explicit in conveying that, when I say it works for me, that's with zero changes to my existing .vimrc where I had both ttimeout and ttimeoutlen set (thereby mimicking existing Vim behavior and maintaining 1:1 backwards compatibility). Success! :rocket: