initial file open sometimes replaces character under cursor with 'g'

[rcaputo]

Problem

Frequently, but not always, the first file opened from the command line will have the character under the cursor replaced by the letter 'g'. This seems to only occur when set nottimeout is enabled. The inconsistency suggests a startup race condition.

Steps to reproduce

nvim --clean --cmd 'set nocompatible' --cmd 'set nottimeout' ~/.vimrc

Removing the --cmd 'set nottimeout' seems to greatly reduce if not eliminate the issue.

Expected behavior

I expect the file to appear in the buffer as it does on disk. The buffer state should initially be unmodified.

Neovim version (nvim -v)

% nvim -v NVIM v0.10.0 Build type: Release LuaJIT 2.1.1713773202

Vim (not Nvim) behaves the same?

no, vim 9.0.1544 (nor a previous forgotten nvim 0.9.x version)

Operating system/version

macOS 11.7.10

Terminal name/version

Reproduced with two: iTerm2, Wezterm

$TERM environment variable

iTerm2:xterm-256color, Wezterm:wezterm (with terminfo installed)

Installation

brew install neovim

[justinmk]

Does it actually change the buffer contents or is it only the display? Does CTRL-L clear it?

[rcaputo]

Changes the buffer contents. Puts it into a modified state. Attempting to immediately :q will result in

E37: No write since last change
E162: No write since last change for buffer "/Users/me/.vimrc"

u will undo the change.

My wild, uninformed guess is that nottimeout is somehow (directly or indirectly) affecting startup timing so that some terminal reporting is being interpreted as keystrokes.

One conspiracy-level theory might be that it causes ttimeoutlen to briefly behave as if it's 0 milliseconds at just the right moment.

[nyorem]

I'm having the same problem: I tend to use Ctrl-Z+fg to switch between neovim and my terminal and almost everytime I come back to neovim, some random text is being pasted.

On my side, I had "set ttimeoutlen=0" in my configuration. Removing it fixes the issue.

[zeertzjq]

It seems that the behavior of 'nottimeout' is not documented, and its current behavior is the opposite of Vim's: in Vim 'nottimeout' means infinite timeout, while in Nvim 'nottimeout' means zero timeout.

[rcaputo]

I looked to see how p_timeout is treated elsewhere, in case it has a similar interpretation when false.

I found two instances. Both involve p_ttimeout.

Here ESC in insert mode seems to always be treated as a single keystroke if both p_timeout and p_ttimeout are false: https://github.com/neovim/neovim/blob/5c33815448e11b514678f39cecc74e68131d4628/src/nvim/getchar.c#L2637-L2638

But a simple test passes: set notimeout and set nottimeout, go into insert mode, and press PageUp or PageDown. This works fine, so the code isn't doing what I thought it did.

The wait time in the inchar() call above is hard-coded at 25 milliseconds. Should it be (int)p_ttm?

Here the semantics seem to be correct. If both p_timeout and p_ttimeout are false, then the wait time for the next keystroke may be indefinite: https://github.com/neovim/neovim/blob/5c33815448e11b514678f39cecc74e68131d4628/src/nvim/getchar.c#L2827-L2841

[drewfish]

I ran into this too when I had the following set

set nottimeout
set timeout
set timeoutlen=1000
set ttimeoutlen=-1

I had to comment out BOTH nottimeout and ttimeoutlen for the issue to go away.

When I had the issue and the following set, opening a file would lead to the first character of the line from last edit being changed to a g AND the cursor would be at the start of the last word on the previous line.

autocmd BufReadPost * if line("'\"") > 0 && line("'\"") <= line("$") | exe "normal g'\"" | endif

I'm using

$ nvim -v
NVIM v0.10.2
Build type: Release
LuaJIT 2.1.1731601260

[msteed]

I can reproduce similar buffer corruption on startup with this init.vim:

set ttimeoutlen=10
colorscheme darkblue

The problem may be reproducible without calling colorscheme, but having that present causes lots of buffer corruption about 30% of the time that I start nvim. Instead of a single character being replaced, I see tens or hundreds of characters written to the buffer. Obviously there are many vim commands running as part of colorscheme, which complicates things a bit, but it does seem to make the issue easier to reproduce.

I see this with nvim 0.10.3 and 0.10.2. Vim 9.1 is unaffected.

[justinmk]

why was my last comment deleted?

is your comment adding new information to this issue?

[iniw]

To anyone that runs into this: set ttimeoutlen=0 instead of setting nottimeout. It achieves the same thing (or at least seems to) while not suffering from this peculiar issue.