Python error popping when oppening a file

[TheMeaningfulEngineer]

Am getting unexpected behavior sometimes when using neovim-remote.
I haven't yet traced the exact series of steps on how to reproduce it.

Config/versions:

neovim-remote==2.1.1
NVIM v0.3.1

$ tail ~/.bashrc 
export PATH="$PATH:~/.local/bin"

alias vi='nvr -s'
alias vim='nvr -s'

$ cat ~/.config/nvim/init.vim 
set nohlsearch
set number
set tabstop=4 shiftwidth=4 expandtab

set hidden
colorscheme ron
set number relativenumber

call plug#begin('~/.config/nvim/plugin/plugged')
Plug 'vim-syntastic/syntastic'
call plug#end()

let g:syntastic_always_populate_loc_list = 1
let g:syntastic_auto_loc_list = 1
let g:syntastic_check_on_open = 1
let g:syntastic_check_on_wq = 0

let g:syntastic_python_flake8_args = "--ignore=E402,E501,E221"
let g:syntastic_python_checkers=['flake8']

tnoremap <Esc> <C-\><C-n>

Error

Traceback (most recent call last):
File "/home/user/.local/lib/python3.6/site-packages/nvr/nvr.py", line 126, in execute self.fnameescaped_command('edit', fname)
File "/home/user/.local/lib/python3.6/site-packages/nvr/nvr.py", line 92, in fnameescaped_command
self.server.command('{} {}'.format(cmd, path))
File "/home/user/.local/lib/python3.6/site-packages/pynvim/api/nvim.py", line 287, in command
return self.request('nvim_command', string, **kwargs)ed')
File "/home/user/.local/lib/python3.6/site-packages/pynvim/api/nvim.py", line 182, in request
res = self._session.request(name, *args, **kwargs)
File "/home/user/.local/lib/python3.6/site-packages/pynvim/msgpack_rpc/session.py", line 102, in request
raise self.error_wrapper(err)

I have filtered out this error message, it usually comes pushed into the text of the opened file.

In the video, I need to press enter to get from the welcome screen to the opened file with the error.

I have noticed that this doesn't happen for new files.

[mhinz]

Let's analyze this!

First off, yeah, printing errors over the screen is not nice. The problem is that the errors stems not from neovim-remote, but its only dependency pynvim.

Anyway, the last line (in the gif) says E325: ATTENTION. Usually you can lookup all error code using the inline help; :h E325. So, it somehow has to do with swapfiles. (Check ~/.local/share/nvim/swap/*.) That would explain why it doesn't happen for new files.

Even knowing that, I can't really reproduce it yet. Because when I try to open a file that has a swap file, I get the usual choice of edit read-only, edit anyway, abort, save, quit etc.

[TheMeaningfulEngineer]

Thanks, will post the content of ~/.local/share/nvim/swap/* once I'm having the issue again.

[TheMeaningfulEngineer]

Hey @mhinz
managed to get the error again.
It eventually got blocked in a new state while I was trying to get more info on it.

Now it blocks on:

hint: Waiting for your editor to close the file...

Once I press enter it gets into read-only mode.

The swap file contains some references to vim 8.

user@user-pc:~/.local/share/nvim/swap$ cat ~/.local/share/nvim/swap/*
b0VIM 8.0����\�\��Wuseruser-pc~user/personal-workspace/themeaningfulengineer.gitlab.io/.git/COMMIT_EDITMSGutf-8	U3210#"! ��Utp��
                                        ��adh��
���##   modified:   2018-09-29-bitbake-syntax-highlight-in-vim.md# Changes to be committed:## Your branch is up to date with 'origin/bitbake-syntax-in-nvim'.# On branch bitbake-syntax-in-nvim## with '#' will be ignored, and an empty message aborts the commit.# Please enter the commit message for your changes. Lines startingb0VIM 8.0��Auseruser-pc	U3210#"! ��Utp�����ad�����

Removing the swap file manually always fixes the problem.

[mhinz]

With the default value of shortmess, I can reproduce your issue.

Can you put this in your vimrc and try to reproduce it once again?

set shortmess-=F

I think with this you should get a proper swap file exists dialog.

[mhinz]

Okay, I just pushed the workaround that nvr itself sets shortmess-=F now. Please test if the latest neovim-remote works as expected for you!

That said, if you have many swap files, you're doing something wrong. ;-) E.g. some terminal emulators simply kill their child processen when they get closed.

[TheMeaningfulEngineer]

Updated. Thanks 👍
Will post when I have new findings.

That said, if you have many swap files, you're doing something wrong. ;-) E.g. some terminal emulators simply kill their child processen when they get closed.

I have noticed the swap files existing even when there aren't any vims open.
Possibly due to what you've mentioned (killing the terminal with vim open).

That said, and with the intention to be openhearted and not cocky, why would
this be something wrong on the user side vs a falsely identified use case in vim (or a feature that
hasn't matured yet).

Couldn't vim discard swap files if there isn't an active buffer related to that file?

[mhinz]

Couldn't vim discard swap files if there isn't an active buffer related to that file?

When you open a file, the corresponding swap file gets created, and usually it's removed again when the file buffer gets closed.

In the best case your swap directory would be empty. Their sole purpose is to recover files that might have been corrupted during an unexpected close of Vim (segfault in Vim due to a bug, terminal killing Vim on closing, blackout, etc.)

So, when all Vims are closed and you still have swap files, feel free to remove them.

why would this be something wrong on the user side vs a falsely identified use case in vim (or a feature that hasn't matured yet

I absolutely consider this a Nvim bug or rather a bug in pynvim. My latest commit is merely a workaround.

When you just do nvim -u NORC ~/foo in one shell, and nvim -u NORC ~/foo again in another shell, you do get the correct swap file exists dialog despite the default 'shortmess' containing F. I try to come up with a minimal example that reproduces this bug and report it.

[TheMeaningfulEngineer]

Their sole purpose is to recover files that might have been corrupted during an unexpected close of Vim (segfault in Vim due to a bug, terminal killing Vim on closing, blackout, etc.)

I got stuck in a mindset where it's main purpose was to warn you that you're editing a file that
is open already. This clears things up, thanks :)

[mhinz]

Okay, so I had a conversation with @bfredl (a pynvim developer). The situation is complicated. :-P

neovim-remote uses pynvim to talk to nvim. pynvim uses nvim's RPC function nvim_command() (:h nvim_command()) But.. there is a difference between :edit file and nvim_command('edit file'). The latter is not really playing well with interactive things like the swap file exists dialog. It also depends on which state src/nvim/message.c is in.

BTW, in your above case, Nvim wasn't blocking, the dialog was in effect, but the text wasn't shown. So it waited for pressing a, r etc. for abort, recover etc.

Long story short, shortmess-=F is the best we can do currently.

[mhinz]

I also just learned that it's already fixed on master! neovim/neovim#9034

We both tested with the 0.3.1 release. So, the above workaround won't even be needed for the upcoming release.

[mhinz]

I consider this fixed. I'll remove the workaround in the next release after 0.3.2 (which is to be released in the next days) gets released.

Thanks for bringing this up!