RPC call (K_EVENT) completes pending op (d, y, ...)

[lunixbochs]

• nvim --version: v0.2.0-624-gddab466, v0.1.6
• Operating system/version: macOS
• Terminal name/version: Python 2/3

Actual behaviour

input('d'), nvim_buf_get_lines(), input('d') will either not delete a line, or will delete one line per input('d') depending on context. Yank via input('y') has the same behavior.

Expected behaviour

input('d'), nvim_buf_get_lines(), input('d') should act the same as input('dd'), or the API should expose some way of indicating a single input of d isn't finished so I shouldn't get the buffer yet.

Steps to reproduce using nvim -u NORC

import neovim

def setup(p):
    global n
    n = neovim.attach('child', argv=['/usr/local/bin/nvim', '--embed'])
    n.command('enew!')
    n.current.buffer[:] = ['line 1', 'line 2', 'line 3']
    print('')
    print('<new instance p={}>'.format(p))

def pbuf():
    for i, line in enumerate(n.current.buffer):
        i += 1
        if i == n.eval('line(".")'):
            i = '*'
        print('{} | {:s}'.format(i, line))

def run(*args, **kwargs):
    p = kwargs.get('p', True)
    setup(p)
    fn = n.input
    for arg in args:
        print('cmd: {:s}({:s})'.format(fn.__name__, repr(arg)))
        fn(arg)
        if p: pbuf()

# case 1
print('-' * 20)
print("case 1: input('d') deletes line without waiting for more input")
run('<esc>G', 'd', 'd', 'd', 'd')

# case 2
print('')
print('-' * 20)
print("case 2: input('d'), input('d') is a noop, but input('G') or input('dd') converts into case 1")
run('d', 'd')
run(':3\n', 'd', 'd')
run(':3\n', 'dd', 'd', 'd')
# works
run('d', 'd', p=False)
pbuf()

Here's my output: https://gist.github.com/lunixbochs/582b2435c6c2ba7e8f12fd2ee7df2f7f

Note the last case with p=False that doesn't query buf[:] will exhibit the correct output.

[Shougo]

Related problem: Shougo/deoplete.nvim#477

ale uses timer feature.

[phmarek]

Is this possibly also the reason why some plugin doesn't get invoked repeatedly?

Ie. one plugin does

    if mode() == 'i' || mode() == 'I' || mode() == 'r' || mode() == 'R'
        if bufname('%') != g:slimv_sldb_name && bufname('%') != g:slimv_inspect_name && bufname('%') != g:slimv_threads_name
            " Put '<Insert>' twice into the typeahead buffer, which should not do anything
            " just switch to replace/insert mode then back to insert/replace mode
            " But don't do this for readonly buffers
            call feedkeys("\<insert>\<insert>")
        endif
    else
        " Put an incomplete 'f' command and an Esc into the typeahead buffer
        call feedkeys("f\e", 'n')
    endif

but this doesn't work any more; I can call the function registered for CursorHold myself, but this automatic re-triggering doesn't run.
Might that be related?

[lunixbochs]

That's perfect, as long as it makes these operators fully blocking. I can just follow up with the <esc> equivalent if a user switches contexts.

…

On Jul 9, 2017, at 12:33 PM, Justin M. Keyes ***@***.***> wrote: @lunixbochs @Chillee @phmarek :set notimeout seems to workaround for this issue, in case that helps in the meantime. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[justinmk]

@lunixbochs @Chillee @phmarek I spoke too soon, :set timeout only helps the similar case where :term output provokes this symptom. It doesn't help for external RPC calls. I'm working on a fix.

[benley]

Searchable comment to maybe save someone 20 minutes of digging: YouCompleteMe seems to trigger this issue pretty reliably.

[tbodt]

This appears to also be triggered by a focus lost event, e.g. d followed by losing focus will cause a line to be deleted.

[gsf]

@tbodt Thanks for that bit of info about losing focus, made me realize why I kept hitting this bug.

With neovim terminal running something like "top" in another window or tab, the current window will lose focus every time that buffer is updated, triggering this issue.

Update: Also happens even if the terminal buffer is hidden, not in another window or tab.

[justinmk]

#7230 resolves this issue for operator-pending mode. Note also that RPCs are not blocked during operator-pending mode. We've decided that's it better to allow that and fix any resulting problems. If you notice any crashes during operator-pending mode, please report it.

#7230 does not fix the problem for unfinished mappings (this is a different state than operator-pending mode). (Update: that's wrong; map-pending is also fine. However, RPCs will block during map-pending, currently. see ce852ba)

[justinmk]

cc @lunixbochs @Chillee

[Chillee]

Nice! What's the easiest way of getting the most up to date neovim version?

[justinmk]

The releases page: https://github.com/neovim/neovim/releases

Or build from source.

[carleryd]

I'm still getting this double delete behaviour after installing NeoVIM 0.2.1 which was just released.
The package that is causing problems for me is w0rp/ale but the over at dense-analysis/ale#967 wOrp says it's a bug with NeoVIM that should have been fixed.

$ nvim
NVIM v0.2.2-5-ge98bcf0
Build type: Release
LuaJIT 2.0.5

Am I not using the correct version? Is anyone else having these problems still?