Input buffer: Attempt to delete a buffer that is in use about vlime

[rknegjens]

I have the same issue.

I'm using pathogen to load vlime.

Same vim, also on archlinux:

VIM - Vi IMproved 8.2 (2019 Dec 12, compiled Jan 26 2020 11:45:38)
Included patches: 1-148
Compiled by Arch Linux

SBCL 2.0.1

ceee9fe (HEAD, origin/master, origin/HEAD, master) Fix *json-cache* to work on other implementations than SBCL.

[mwgkgk]

Developments:

• Issue is not reproducible in NeoVim.

• Here's where it's triggered from:

In autoload/vlime/ui/input.vim,
In function vlime#ui#input#FromBuffer:

augroup VlimeInputBufferLeaveAu
    autocmd!
    execute 'autocmd BufWinLeave <buffer> bunload!' buf
augroup end

:bunload! discards changes, closes any windows for this buffer, and frees the memory allocated for it. BufWinLeave is triggered before a buffer is removed from a window, not when it's still visible in another window, also triggered when exiting.

The Input buffer has setbufvar(buf, '&buflisted', 0), which means it doesn't show up in the operations involving the buffer list. To show all buffers the including unlisted ones, we can use :buffers!. Which, reasonably enough, the Input buffer shows up in, regardless of whether the above autocommand is present.

So the idea behind this line is to unload the memory allocated for whatever content we've put into the buffer, before we close it without removing from the (hidden-) buffer list. If we wanted to also remove it from the (hidden-) buffer list, we would use bdelete! instead of bunload!. Reasonably enough (since the former includes the latter), either command causes the same error.

Moving the autocommand up the autocommand stack to BufLeave solves the error, however this autocommand is triggered upon switching windows as well, which means we can destroy the buffer before we submit, which is undesirable. The autocommands down the stack that we could attach to, are (BufUnload, BufDelete, ...) are not exactly what we need either, and also happen to trigger the error (even if the construct itself now makes little sense). We are attempting to delete a buffer that is in use. The E937 help pertains to a group of autocommand-related errors and does not clear up this issue.

• We run bdelete! when we submit the Input buffer anyways:

As defined in the same function vlime#ui#input#FromBuffer we were discussing previously:

nnoremap <buffer> <silent> <cr> :call vlime#ui#input#FromBufferComplete()<cr>

vlime#ui#input#FromBufferComplete calls the clean up by itself:

execute 'bdelete!' input_buf

Which means the following: the buffer IS being run bdelete! on, (which itself triggers bunload!), when it's submitted with the <CR> key.

So the only case where the problematic autocommand is relevant, is when we forcibly close the buffer without submitting it first. Which is problematic in itself, because further Lisp calls that would otherwise trigger the buffer, are put on hold until we find the buffer number in the buffers! list (because it's otherwise hidden from buffer-related commands), and then switch to it by it's number, e.g. :b 5. After that the situation resolves itself and the Input buffer will appear as many times as it was needed for the queued calls.

An alternative to deleting the autocommand outright, is to place it in an optional nvim block:

if has('nvim')
    augroup VlimeInputBufferLeaveAu
        autocmd!
        execute 'autocmd BufWinLeave <buffer> bunload!' buf
    augroup end
endif

[mwgkgk]

Another way of addressing this can be seen in pull request #48, which is handling the unload in a try block:

function! s:BufUnload(buf) abort
  try
    execute 'bunload!' a:buf
  catch /^Vim\%((\a\+)\)\=:E937:/
    return
  endtry
endfunction

augroup VlimeInputBufferLeaveAu
    autocmd!
    execute 'autocmd BufWinLeave <buffer> call s:BufUnload(' buf ')'
augroup end

Which seems more idiomatic than introducing an unwarranted nvim branch like above. I humbly call for @fukamachi to merge it!

[mwgkgk]

Deleting the problematic block entirely also seems like a valid option, as the functionality it brings is highly questionable, as discussed in above #51 (comment).