Vifm.vim remains opened in a hidden buffer after running `vim <DIR>` and picking a file
Description
There seems to be a usability issue with vifm.vim w/embedding + netrw replacement.
When vim is started as vim <DIR> directly into a vifm.vim buffer, after picking a file vifm.vim does not terminate and remains in a hidden buffer. Thus, when I edit the file and attempt to exit Vim via :q, I get an error:
E947: Job still running in buffer "vifm: edit"
If I then pick another file, the embedded instance does terminate. ISTM that it should do so in the beginning as well.
Environment
Thanks for the report. There is clearly an issue. Vifm does terminate after picking a file, otherwise nothing would get opened in Vim, but Vifm is started again in a new buffer right after that.
Vifm does terminate after picking a file, otherwise nothing would get opened in Vim, but Vifm is started again in a new buffer right after that.
Ah, right. I described the user-visible effects :-)
Hi. Similar issue here. I noticed the same: vifm does keep a hidden buffer opened (although i do not experience the same problem as op).
Ive tried to troubleshoot and this is all ive got:
function! data.on_exit(id, code, event) abort
"-------------------------------------------------TROUBLESHOOT
let term_buf_to_delete = bufnr('%')
echomsg term_buf_to_delete
"-------------------------------------------------------------------
if (bufnr('%') == bufnr('#') || !bufexists(0)) && !self.split
enew
else
echomsg 'Before swaping: ' . bufnr('#')
silent! buffer #
endif
echomsg 'After swapping, before deleting: ' . bufnr('#')
silent! bdelete! #
echomsg 'After deleting: ' . bufnr('#')
if self.split
silent! close
endif
if self.cwdjob != 0
call jobstop(self.cwdjob)
endif
call s:HandleRunResults(a:code, self.listf, self.typef, self.editcmd,
\ self.snapshot)
"----------------------------------------------TROUBLESHOOT
if bufexists(term_buf_to_delete)
"echomsg term_buf_to_delete
echomsg 'The buffer keeps existing. Its number is ' . term_buf_to_delete
bdelete! term_buf_to_delete
else
echomsg 'Buffer does not exist. Number: ' . term_buf_to_delete
endif
endfunction
"-----------------------------------------------------------------------------------------
In the last function, the silent! from delete is removed. It's kinda weird because I enter the if statement and I even get the message 'the buffer keeps existing' but then I receive the error of the non silent bdelete.
Any updates on this? I really like this plugin.
I think I've figured it out. Try using bwipeout instead of bdelete. Since :bdelete doesn't actually remove the buffer, but just makes it harder to access, it probably remains recorded as an alternative buffer and closing the first instance of Vifm ends up processing the same paths again (because directories are handled on BufEnter event).
I've tried with bwipeout but it behaved the same.
Im so mad i cant fix it cause this is the best file manager by far.
Updates. I managed to get terminal vifm inside a floaterm wrapper.
With these settings ive got it exactly as i had it before:
autocmd FileType floaterm setlocal nonumber norelativenumber
let g:floaterm_opener = 'drop'
let g:floaterm_wintype = 'split'
let g:floaterm_position = 'botright'
let g:floaterm_height = 0.7
command! Ffm silent! FloatermNew vifm
nnoremap <leader>vh :Ffm<CR>
The issue of buffer replication does not happen this way.
Sorry, I wasn't clear enough, the place where bwipeout makes difference over bdelete is in https://github.com/vifm/vifm.vim/blob/91d50ba57da96e0bd467ecb768914573d09d770d/plugin/vifm.vim#L496-L503
I let the previous chunk as it was originally and modified just the one line 503 of the snippet you referred to.
I don't know if i'm misunderstanding again, for it does not work for me.
Weird, for me using bwipeout makes :ls! print only a single buffer in both Vim and neovim and the OP's issue is completely resolved. I'll push the fix and close this, feel free to create a separate issue if the problem won't go away for you after that.